Notepad++

Sergey Gromov snake.scaly at gmail.com
Mon Aug 17 19:14:40 PDT 2009


Mon, 17 Aug 2009 21:23:56 +0100, Stewart Gordon wrote:

> Sergey Gromov wrote:
>> Highlighting the whole file every time a charater is typed is slow.
>> Scintilla doesn't do that.  It provides the lexer with a range of
>> changed lines.  The lexer is then free to choose a larger range if it
>> cannot deduce context from the initial range.  I tried to ignore this
>> range and re-highlight the whole file in my lexer.  The performance was
>> unacceptable.
> 
> Of course.  I suppose now that the right strategy is line-by-line with 
> some preservation of state between lines:
> 
> - Keep a note of the state at the beginning of each line
> - When something is changed, re-highlight those lines that have changed
> - Carry on re-highlighting until the state is back in sync with what was 
> there before.  If this means going way beyond the visible area of the 
> file, record the state of the next however many lines as unknown (so 
> that it will have another go when/if those lines are later scrolled into 
> view).
> - If a range of lines that has just come into view begins in unknown 
> state, it's up to the particular lexer module to start from the first 
> visible line or backtrack as far as it likes to get some context.
> 
> Is this anything like how Scintilla works?

Exactly.  There is a 32-bit "style" known for every character, plus
another 32-bit field associated with every line.  A lexer is free to use
these fields for any purpose, except the lower byte of a style defines
the characters' color.

> 
> <snip>
>> It's actually trivial* to implement a lexer for Scintilla which would
>> work exactly as TextPad does, including use of the same configuration
>> files.
>> 
>> * That is, if you know exactly how TextPad works.
> 
> It would also be straightforward to improve TextPad's scheme to support 
> an arbitrary number of string/comment types.  How about this as an 
> all-in-one replacement for TP's comment and string syntax directives?
> 
> [...]
> 
> [DelimitedToken8]
> Start = "
> End = "
> Esc = \
> Type = String
> SpanLines = Yes
> Nest = No
> 
> [DelimitedToken9]
> Start = '
> End = '
> Esc = \
> Type = Char
> SpanLines = No
> Nest = No
> 
> There, we have all of D1 covered now, and not a regexp in sight.

Yes and no, because your ad-hoc format doesn't cover subtle differences
between C and D strings.  Like C strings don't support embedded EOLs.
Though you may consider this minor.

> <snip>
>> Basically yes, but they're going to be much more complex.  3Lu...5 is
>> also a range.  0x3e22.f5p6fi is a valid floating-point number.  And
>> still, regexps don't nest.  Don't you want to highlight DDoc sections
>> and macros?
> 
> That would be nice as well, as would being able to do things with 
> Doxygen comments.  But let's not try to run before we can walk.

This assumes that TextPad could run at some point.  ;)  This is exactly
where I'm sceptical.  I think that when it runs it'll have so many weird
rules and settings that it won't be fun anymore.  And they won't be
powerful enough for anything authors didn't consider anyway.



More information about the Digitalmars-d mailing list