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
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
