On Mon, Feb 13, 2012 at 19:30, Martin <[email protected]> wrote: > On 13/02/2012 16:49, Martin wrote: > >> On 13/02/2012 08:19, Hans-Peter Diettrich wrote: >> >>> Martin schrieb: >>> >>>> 2. In declaration of external functions like the following >>>>> >>>>> procedure P; external 'someLib' name 'someName'; >>>>> the "name" is like a keyword. So it would be nice if it'll be in bold >>>>> font. >>>>> >>>> >>>> I have plans to make changes that could reduce those issues, but not >>>> very soon... >>>> >>> >>> Will it be possible to disable context sensitive processing, so that it >>> can be turned off when it turns out to slow down or otherwise affect >>> working with text? Here I mean some "local" shortcuts or flags, affecting >>> only the currently edited file. >>> >> >> They could be turned off for display. >> Turning them off for parsing, would add extra cod into the parser. So >> unless duplicating the entire parser it might not do much good. >> > > Ok, after some thought, it looks like: > - do-able: procedure P; external 'someLib' name 'someName'; > - not currently practicable: raise at > > The highlighter works linebased. After finishing a line, it may have to > look at another line, maybe even other file. It must store the entire state > at the end of the line. In fact it has to store and keep the entire state > of the end of each single line. > > The highlighter does not go forward and backward. It scans one token at a > time, then the next. > > This already leads to limitations: a class forward declaration (" TFoo = > class;") is a foldable block, ending at the ";" (but to notice this, you > must put the ";" ons a new line) > > ----------- > As a general rule: If "at" was highlighted, then it should be consistent. > "In most cases" (e.g. as long as on the same line) is *not* an acceptable > solution. > > ----------- > The amount of states between "procedure" and "name" is fairly limited (and > also to some extend already stored, for other reasons). > > "raise at" can be complex > > "at" can be a clase name, or name of a constructor, or a function > returning the object or class > raise At.Create; > raise Foo.At(); > raise At(); > raise At().Create; > raise At.At.At.At; > and with operator overloading, the object for the "raise" can be the > result of an expression: > Raise AFooException + At; > > So a full pascal expression parser would be needed. That is not the > problem (could even be fast enough). But each possible state in an > expression (before/after dot/operater // bracket nest-lvl ...) must be > allowed to be stored. That explodes memory cost (storage capacity is needed > *everywhere*, even if there is not a single "raise at" at all) > Maybe it can be reduced, but it is probably a lot of work to implement... > > This may change in future. But not without major rework of the highlighter
Interesting. Thank you. A whole rewrite like that, however allow you to also create support for additional cases, but it's not that crucial to have it. Ido > > > > -- > ______________________________**_________________ > Lazarus mailing list > [email protected].**freepascal.org<[email protected]> > http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus> >
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
