herbert breunung wrote:
the first "#" in the initial shebang is sometimes bracelighted
If you could describe a reproducible test case, I'd be happy to
look at it. I do try to keep track of LexPerl bug reports, but I
haven't come across this before.
>My preference for looking backwards and forwards is simply to
>avoid the need for Scintilla to store additional state
>information, unless it is absolutely unavoidable.
why not use the normal style information scintilla provides. you can
trust what its
unchanged and if the unchanged is lexed as var you can trust them and
continue from
but yes there is no information about how many and what types of braces
still to close.
Err... "normal style information"? I don't understand. Doesn't
lexers produce style information? Do you mean folding information?
Your sentence is rather incoherent; I don't understand what you
are trying to say.
[snip] but even when an extra data stucture is bad,
you get much more speed with it and avoid duplication.
Style is 8 bits. I would want to be very careful about how I use
those bits. Hijack the folding bits? Maybe, but that's a rather
bad way to implement things. Finally, I wouldn't want to go into
storing state information in the lexer itself.
indeed i believe it will be scintilla untypically
slow if you look too much forward and below.
The localized lookbacks currently used are quite efficient. For
the '/', I've taken a look at lookback lengths during debugging,
and usually the lookback length is very short. If lookback in
LexPerl isn't localized, then I would of course consider adding
state information. My 'vice' is that I am extremely conservative
when it comes to adding more state information.
"Get much more speed" with extra data structures and "scintilla
untypically slow"? Speculation. Jumping to conclusion. So far I
haven't seen any bad corner cases for the current lookback lexing
scheme. Please do report to the list if there is such a case.
How big is the win when using state information over doing
lookbacks? It doesn't exactly cripple Perl... How many bits of
state do we need, can it fit in? Even if the win is big, does it
matter during typical use? What about those editors that use long
regexes, are they fast? Does the extra fraction of performance
matter? From an engineering point of view, think of this analogy:
Should I build an airframe in titanium when aluminum alloys are
good enough?
I'm not really worried about implementation or performance; my
focus is on how to lex Perl code properly -- find a proper
solution, and only then see how it can be implemented. Anyway,
both using state and using lookbacks are possible solutions,
obviously neither is 'wrong', so anyone who wants to take a stab
at redoing the lexer is welcome to do so.
--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
