|
Re: Manager class: msg#00039lang.nemerle.devel
06-05-29, NoiseEHC <NoiseEHC@xxxxxxxxxxx> napisał(a): LOL, just spent some time to read the forum. Seems that the volume of It seems many people prefer forum, which is a bit strange for me, because it is harder to be in sync with new messages. But anyway, let us not start any list/forum war. Now, as I read all of Vlad's messages it seems that we have another Hm, it doesn't work for me too. We should ask Vlad if it is possible to move their implementation to nemerle.org repository. It will probably make things more accessible to everybody and allow us some more coordination of efforts. Ahh, and Nazgul, please do not remove the LexerColorizer. I tried to use This is a bit strange, since LexerString and LexerColorizer allow very similar functionality - they just hold a string and position in it. So in general if you assign previous position to LexerString, it should correctly "back in time", though there are several fields, which actually hold the state of lexing - they are used in preprocessor directives parsing. It is quite interesting how MS implemented this stuff in C# bindings, since VS seems to behave quite intelligent with respect to preprocessor directives - and in general this requite more than a simple int state. My original idea for LexerColorizer was that it should be fast and it should colorize the default code correctly (e.g. assuming that standard code macros are loaded, not considering preprocessor directives, etc.). Then in the less frequent parsing passes we could use LexerString to additionally colorize some new keywords or preprocessor stuff. But the problem is that if we want for example matching of parenthesis we must use LexerString anyway. So it is not clear for me if maintaining two separate implementations of Lexer makes any sense... but maybe yes :)
The folks from rsdn.ru seems to check the forum more frequently than mail ;) So probably for discussions about completion engine and VS you should stick there.
You probably need to initialize the ManagerClass object. Now as we have the more object-oriented structure, it should be reasonably easy to subclass ManagerClass (or use the Nemerle.Completion.Engine) and make it perform only some chosen set of steps (like only initialize the library references and then perform lexing) on the Run method. I'm looking forward for defining some more methods in ManagerClass, which could be overridden in subclasses, so we can easily enable / disable some compilation steps or simply jump to single step. So the idea is to always call some methods defined in ManagerClass and avoid directly using other compiler's API.
-- Kamil Skalski http://nazgul.omega.pl
|
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Nemerle add-in for MonoDevelop with Completion, Alejandro Serrano |
|---|---|
| Next by Date: | Re: Manager class, Mark Haniford |
| Previous by Thread: | Re: Manager class, NoiseEHC |
| Next by Thread: | Re: Manager class, NoiseEHC |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |