Sergey Gromov wrote:
Mon, 17 Aug 2009 21:23:56 +0100, Stewart Gordon wrote:
<snip>
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.
Does it keep around in memory the style of every character, or only the
32-bit field associated with the line so that the lexer can re-style the
characters on repaint/scroll?
<snip>
[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.
I don't understand. How does SpanLines not achieve this?
Then what _does_ SpanLines achieve according to whatever conclusion
you've come to?
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.
You're right - it turns out TP doesn't get all the D floating point
notations right. It appears that TP has hard-coded the syntax of C
numeric literals. I must've just not noticed since I had never before
changed the number colour from the same as the default text colour.
Maybe we do want regexps for all these floating point notations after all.
;) 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.
Maybe someone can come up with something....
Stewart.
