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

[ik]

On Mon, Feb 13, 2012 at 19:30, Martin <lazarus at mfriebe.de> 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
> Lazarus at lists.lazarus.**freepascal.org<Lazarus at lists.lazarus.freepascal.org>
> http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20120214/aa2f18e1/attachment-0003.html>