[TxMt] syntax tool

[Chris Thomas]

On Jan 15, 2005, at 5:36 PM, Eric Hsu wrote:
[snip]


> (1) bundle writers standardized the 'names' of the various color 
> classes and
> (2) somebody wrote a little GUI that let people pick a standard set of 
> colors with the color picker and then propagate the changes across all 
> bundles.
A key question might be: how far along is Allan with the syntax 
highlighting rewrite?

But either way, (1) must be done. I compiled a list of the names of the 
current highlighting "classes" as represented in the syntax files in 
the SVN repository. There is a certain amount of redundancy in the 
list, especially for comments and strings. But once you eliminate that 
redundancy, you still need to distinguish patterns with different 
syntax, but of the same class, in the language, as for, say "Pascal 
comment style 1" and "Pascal comment style 2"? And also the various 
different types of string syntaxes available in languages like Perl and 
Ruby. You really want the forthcoming hierarchical CSS-inspired system.

Of course, what one could do is establish hierarchy using the names, 
and then have the editor parse the name keys. So you'd have 
'comment.block.pascal-one' and 'comment.block.pascal-two', and the 
editor need only see 'comment' as the top-level element to understand 
that it's a member of the general comment class. You might have a 
general taxonomy like:

keywords.*
keywords.types.*  # built-in types: int, bool, float, real
keywords.control.*  # distinguishing flow control: if, then, else, 
while, end
comments.*
comments.line.*  # comment to end of line
comments.line.doc.*  # documentation comment to end of line
comments.block.*  # comment between delimiters
comments.block.doc.*  # documentation comment between delimiters
invalid.*  # invalid markup
strings.double-quoted.*
strings.single-quoted.*
strings.here-document.*
strings.regexp.*
... [imagine appropriate LaTeX and (HT|SG|X)ML markup classes as well]

Syntax files would specialize as needed, so pascal comments might be 
represented by these names:

comments.line.pascal  # pascal has only one style of line comment
comments.block.pascal.ucsd  # or whatever
comments.block.pascal.algol

I don't know what to do exactly with function names and other elements 
that use part of a keyword match ("foregroundColor[2]"). The 
hypothetical editor may have to do additional parsing if it wants to 
support coloring the subcaptures differently from the keyword.

Sorry if this seems rambling, long day...

Chris