On Sun, 17 Dec 2000 14:11:50 -0700 (MST), Nathan Torkington wrote:
>I think the problems with this that were raised in the past are:
> * parsing partial source
> * does this mean that the parser has to reparse the whole sourcefile
> every time you type a character?
Hold it. I don't think that is very practical, and for more than one
reason.
For the editor I'm currently using, the Perl syntax coloring is a bit
simple minded, in that it does its syntax highlighting on a line by line
basis. Yes that does imply that multiline statements and strings won't
be colored properly, but otherwise, it behacves nicely. Why? because,
when I'm working on source, it is very unreasonable to expect that the
source will be a valid Perl program after every single keystroke. So no,
while editing, it is *impossible* to do proper syntax highlighting for
the whole script at all times.
More specifically, I can't be 100% sure that the lines *above* the one
I'm currently editing, are indeed valid Perl. And I don't care, not at
this moment. I definitely do not want these lines above to screw with
the syntax highlighting of the line that I'm currently editing.
So what do I envision? I think we need some sentinels, marker points in
the source, saying: "OK, do not reparse anything above this marker".
What kind of marker? Block ends, or semi-colons, those seem like
reasonable candidates.
We should also know where to stop. Do we indeed want, as soon as we type
one quote, have everything on the right of and below it, to change color
into "quoted string" mode, up until the next quote? Is this a tool, or a
light show?
If we limit the range of what the syntax highlighter affects at any
time, we'll save on processing time too. For example, we can
re-highlight the lines below the one we just edited, as soon as the
cursor leaves the line.
But, the gist of this post is: we don't want to loose the usefulness of
the syntax highlighter, as soon as there is one syntax error in the
script, because this will be the normal situation while editing source.
Parsers are generally very bad at parsing erroneous code.
--
Bart.
