Martin wrote 18 lines
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
