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

[Hans-Peter Diettrich]

Martin schrieb:
> On 13/02/2012 02:13, Bernd wrote:
>> 2012/2/12 ik<idokan at gmail.com>:
>>
>>> Raise Exception.Create('') at get_caller_frame(get_frame);
>>>
>>> Does not paint the "at" code as reserve word.
>>> It is not a reserved word according to the documentation, but on this
>>> specific case, it act as one imho.
>> According to my "Sprachgefühl" this cannot be anything other than a
>> reserved word. Its not an identifier, its not an operator, it can only
>> be a reserved word.

It is a directive, that works only in this context. See property "read" 
and "write"...

>>> Do you think like me, that it should be painted on this case as a 
>>> reserve
>>> word ?
>> +1
> 
> It does not matter how they are named. From a user point of view they 
> could be highlighted. Or at least as an option.
> Such context sensitive stuff is already done in some places.
> 
> The problem is how the parser works. And each context addition adds to 
> the workload. It is enough, if one file contains them, for all to be 
> affected.

And it is very boring, sometimes. Painting is minor issue, but when when 
e.g. some (code) completion offers a list of words, whenever I type an 
period in an XML file, and I have to press ESC to close it, this is very 
nasty :-(


> Also I am not sure if it currently is worth the work (after all it must 
> ONLY be in that very specific context, the way the scanning works, the 
> scanner may only have a fragment of the statement when decision is due)

Right, see:
> 
> There are other things too:
>> 1. Why SynPasHighlighter thinks that "contains" is a keyword (and
>> types it in bold)?

This applies only to library units, but these differ from other units 
only by
   library mylib;
in contrast to
   unit myunit;
near the begin of the file. Should the syntax highlighter really 
remember such subtle file type differences?

>> 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.

Sometimes I wonder how e.g. (foldable) block detection can be so stable, 
when blocks are not properly terminated in currently edited source code. 
Yes, it *is* stable :-)
but I fear that every context sensitive addition might destabilize it.

DoDi