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

[Martin]

On 13/02/2012 08:19, Hans-Peter Diettrich wrote:
> Martin schrieb:
>>
>> 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 :-(

Am I missing something?
The highlighter has nothing to o with code completion. They even use 
different parsers.

The Highlighter, must update after ever edit (each single char). The 
code completion does less frequent

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

I probably write another mail on this

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

It has its limits. But the context stuff is not likely to break it (plus 
there are test cases...)

Example

{$IFDEF}
procedure Foo(a:integer);
{$ELSE}
procedure Foo(a:string);
{$ENDIF}
begin
end;

the parser will see 2 procedures, where only one is.
So "procedure Foo(a:string);" is seen as nested, and all further 
procedures will be too.

That is also very very (1000*very) unlikely, to be fixed. It would be 
major overhead to calculate and store separate folds for every $IF 
path... (and merge them back together...)