Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 15.02.2012 15:32, schrieb Martin: On 15/02/2012 10:51, Sven Barth wrote: Am 15.02.2012 11:36, schrieb Marco van de Voort: On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: 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. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Maybe because the "at" was introduced rather late by Borland and then they didn't want to break compatibility with code that uses "at" as a variable or something. "until" is in the language for a long time (Delphi language, not Pascal language). Same with words like "helper", "read", "write", "default", "requires", "contains". They were all introduced afterwards (though there seem to be exceptions, so it's not easy to decide whether something is a global keyword or a context sensitive one). Correct me, but var until: boolean; does not compile, while var at: boolean; does compile Yes, that is correct. Looking at my message again there might have been a misunderstanding: "until" is in Object Pascal since the beginning, but maybe the "at" part was introduced later. Other keywords like "helper" were also introduced later so instead of breaking working code Borland decided to make them "context sensitive". That's my theory for this. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On 15/02/2012 10:51, Sven Barth wrote: Am 15.02.2012 11:36, schrieb Marco van de Voort: On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: 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. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Maybe because the "at" was introduced rather late by Borland and then they didn't want to break compatibility with code that uses "at" as a variable or something. "until" is in the language for a long time (Delphi language, not Pascal language). Same with words like "helper", "read", "write", "default", "requires", "contains". They were all introduced afterwards (though there seem to be exceptions, so it's not easy to decide whether something is a global keyword or a context sensitive one). Correct me, but var until: boolean; does not compile, while var at: boolean; does compile -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Marco van de Voort schrieb: On Wed, Feb 15, 2012 at 12:12:38PM +0100, Hans-Peter Diettrich wrote: be a reserved word. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Borland made a distinction between *reserved* words and *directives*. Reserved words cannot be used as identifiers, while directives are recognized as something special only in their related context, and can be used as identifiers in all other places. If you ever happened to write a break() or exit() procedure, you'll have noticed that your remaining code may fail with very strange errors, because these take precedence over the language-defined behaviour of "break" or "exit". I do know what they are. This thread is about the why. Why what? One is a decision of the language designers, another one the decision of the syntax highlighter. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 15.02.2012 12:12, schrieb Hans-Peter Diettrich: Marco van de Voort schrieb: On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: 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. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Borland made a distinction between *reserved* words and *directives*. Reserved words cannot be used as identifiers, while directives are recognized as something special only in their related context, and can be used as identifiers in all other places. If you ever happened to write a break() or exit() procedure, you'll have noticed that your remaining code may fail with very strange errors, because these take precedence over the language-defined behaviour of "break" or "exit". "exit" and "break" are different. They are compiler intrinsics, so they are basically functions/procedures. "at" (or "read" in the context of properties) is not an intrinsic, but a token. To take this problem up to eleven: The following code compiles in FPC (and AFAIK Delphi as well): type Message = record ID: LongWord; end; TSomeClass = class procedure Message(var Message: Message); message 23; end; Here only the "message" in front of the "23" is a "keyword" (or better "directive"). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On Wed, Feb 15, 2012 at 12:12:38PM +0100, Hans-Peter Diettrich wrote: > >>> be a reserved word. > >> At is not a reserved word. It works only in the context of a raise > >> statement. > > > > How is this different from "until" ? > > Borland made a distinction between *reserved* words and *directives*. > Reserved words cannot be used as identifiers, while directives are > recognized as something special only in their related context, and can > be used as identifiers in all other places. If you ever happened to > write a break() or exit() procedure, you'll have noticed that your > remaining code may fail with very strange errors, because these take > precedence over the language-defined behaviour of "break" or "exit". I do know what they are. This thread is about the why. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Marco van de Voort schrieb: On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: 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. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Borland made a distinction between *reserved* words and *directives*. Reserved words cannot be used as identifiers, while directives are recognized as something special only in their related context, and can be used as identifiers in all other places. If you ever happened to write a break() or exit() procedure, you'll have noticed that your remaining code may fail with very strange errors, because these take precedence over the language-defined behaviour of "break" or "exit". DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On Wed, Feb 15, 2012 at 12:09:06PM +0100, Sven Barth wrote: > > That was what I thought too initially. But there is also a gramatical > > difference that in the case of repeat..until there is a zero or more > > intermittent statements, while in the case of raise .. at there is one, and > > only exactly one expression? > > What does this have to do with whether this is a keyword or not? If only one expression, there is no conflict possible. If not a keyword, and identifier can be defined as keyword, and the statement can be that keyword. iow raise at at is not ambiguous, the first "at" is the expression, the second the keyword. repeat until until _IS_ ambiguous. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 15.02.2012 12:03, schrieb Marco van de Voort: On Wed, Feb 15, 2012 at 11:51:27AM +0100, Sven Barth wrote: At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Maybe because the "at" was introduced rather late by Borland and then they didn't want to break compatibility with code that uses "at" as a variable or something. "until" is in the language for a long time (Delphi language, not Pascal language). Same with words like "helper", "read", "write", "default", "requires", "contains". They were all introduced afterwards (though there seem to be exceptions, so it's not easy to decide whether something is a global keyword or a context sensitive one). That was what I thought too initially. But there is also a gramatical difference that in the case of repeat..until there is a zero or more intermittent statements, while in the case of raise .. at there is one, and only exactly one expression? What does this have to do with whether this is a keyword or not? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On Wed, Feb 15, 2012 at 11:51:27AM +0100, Sven Barth wrote: > >> > >> At is not a reserved word. It works only in the context of a raise > >> statement. > > > > How is this different from "until" ? > > Maybe because the "at" was introduced rather late by Borland and then > they didn't want to break compatibility with code that uses "at" as a > variable or something. "until" is in the language for a long time > (Delphi language, not Pascal language). Same with words like "helper", > "read", "write", "default", "requires", "contains". They were all > introduced afterwards (though there seem to be exceptions, so it's not > easy to decide whether something is a global keyword or a context > sensitive one). That was what I thought too initially. But there is also a gramatical difference that in the case of repeat..until there is a zero or more intermittent statements, while in the case of raise .. at there is one, and only exactly one expression? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 15.02.2012 11:36, schrieb Marco van de Voort: On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: 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. At is not a reserved word. It works only in the context of a raise statement. How is this different from "until" ? Maybe because the "at" was introduced rather late by Borland and then they didn't want to break compatibility with code that uses "at" as a variable or something. "until" is in the language for a long time (Delphi language, not Pascal language). Same with words like "helper", "read", "write", "default", "requires", "contains". They were all introduced afterwards (though there seem to be exceptions, so it's not easy to decide whether something is a global keyword or a context sensitive one). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On Mon, Feb 13, 2012 at 10:25:34AM +0800, Paul Ishenin wrote: > > 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. > > At is not a reserved word. It works only in the context of a raise > statement. How is this different from "until" ? -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On Mon, Feb 13, 2012 at 19:30, Martin 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@lists.lazarus.**freepascal.org
> http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On 13/02/2012 18:37, Martin wrote: On 13/02/2012 17:57, Hans-Peter Diettrich wrote: Martin schrieb: 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... For such complications I would leave context unhandled. At least it should be possible to disable it, and if only for memory usage reasons. Hence I wrote, that I will not highlight "at" in "raise" at all, for now. Of course, we could make, every "at" highlighted, for those who want that, and switch it on. That is a different topic. And that would not be an highlighter issue at all. That could be done as general markup (though the settings could be stored with dependency on the highlighter). Any text, even without highlighter could have such words... In pascal, I personally would probably mark: debugln and assert. But that is my personal list. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On 13/02/2012 17:57, Hans-Peter Diettrich wrote: Martin schrieb: 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... For such complications I would leave context unhandled. At least it should be possible to disable it, and if only for memory usage reasons. Hence I wrote, that I will not highlight "at" in "raise" at all, for now. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Martin schrieb: 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... For such complications I would leave context unhandled. At least it should be possible to disable it, and if only for memory usage reasons. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
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
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
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...)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 13.02.2012 14:21 schrieb "Hans-Peter Diettrich" : > > Sven Barth schrieb: > > >> You're wrong. "contains" (along with "requires") is only a keyword in package files not library files. > > > Thanks for the correction. > > You're welcome. >> E.g. >> >> package Foobar; >> >> contains >> Foo in 'foo.pp', >> Bar; >> >> requires >> RTL; >> >> end. > > > I couldn't find such files documented anywhere. Are these recognized by FPC, what's their extension? These are normal Delphi package main files. There they have the extension "dpk". For FPC no such extension exists yet, but the compiler can already parse a file like the above (with whatever extension it might have) and tries to create a runtime package (extension "ppl" analog to Delphi's "bpl"). These packages are not useable currently though. Someone started to implement package support in the compiler some years ago, but it was never finished... Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Sven Barth schrieb: You're wrong. "contains" (along with "requires") is only a keyword in package files not library files. Thanks for the correction. E.g. package Foobar; contains Foo in 'foo.pp', Bar; requires RTL; end. I couldn't find such files documented anywhere. Are these recognized by FPC, what's their extension? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Am 13.02.2012 10:28 schrieb "Hans-Peter Diettrich" : >> 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? You're wrong. "contains" (along with "requires") is only a keyword in package files not library files. E.g. package Foobar; contains Foo in 'foo.pp', Bar; requires RTL; end. Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
Martin schrieb:
On 13/02/2012 02:13, Bernd wrote:
2012/2/12 ik:
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
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
On 13/02/2012 02:13, Bernd wrote:
2012/2/12 ik:
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.
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.
I do not think this one will be trouble, it depends what is added next.
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)
There are other things too:
1. Why SynPasHighlighter thinks that "contains" is a keyword (and
types it in bold)?
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...
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
13.02.2012 10:13, Bernd пишет:
2012/2/12 ik:
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.
At is not a reserved word. It works only in the context of a raise
statement.
Best regards,
Paul Ishenin
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Should the "at" word be painted as reserved word ?
2012/2/12 ik :
> 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.
> Do you think like me, that it should be painted on this case as a reserve
> word ?
+1
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Should the "at" word be painted as reserved word ?
Hello,
The Following code:
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.
Do you think like me, that it should be painted on this case as a reserve
word ?
Ido
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
