[Lazarus] Should the "at" word be painted as reserved word ?

[Martin]

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