Made issue 1452. It's an OCompletion problem, really. It reuses the text parsing from ECompletion, which calculates the ranges of the entire text on every invocation. (Scanning the entire SymbolTable once for every undefined token in the text...) Which I guess is fine when invocation is user-initiated, but not so much when it happens automatically as a response to every key press. What I am planning to do, is rewrite it to not discard the context between each invocation, but rather update the type of range under the cursor, and the extent of subsequent ranges based on whether a character/string has been inserted or removed. An easier solution would be to cache the last X queried undefined/partial symbols somewhere (Not in the parser-instance, as a new one is created by the context every time), as that would limit each parsing run to a worstcase of one full scan of the SymbolTable (for the current token). It means an extra cache that has to be maintained though, and feels like working around the problem instead of solving it, so I'd rather do the former. Cheers, Henry On Nov 14, 2009, at 9:45 10PM, Mariano Martinez Peck wrote:
You should then open a bug ticket!
On Fri, Nov 13, 2009 at 1:03 PM, Alexandre Bergel <alexandre@bergel.eu> wrote:
I have not yet investigated the issue but since I guess I must not be the only one to see this happen maybe someone has some thoughts or is already on the issue (although I could not find an issue on the tracker).
+1 You're not the only one
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;<you._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project