I am about to hack up a small Cocoa tool to edit the syntax highlighting of the bundles... it's a pain to do it manually. Would there be any interest among you to distribute it here?
It will be free of course, and I will provide the source.
If you have the time, sure go ahead, but remember that Alan is planning this as a inbuilt feature, so perhaps you're better off spending that time relaxing with a beer.
Then again, if you're sharing the source, you might give Alan a few ideas along the way :)
I vote for relaxing with a beer AND programming. I'd love to see the source. I think Allan is planning something rather general and powerful. In the meantime people would probably appreciate it if
(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.
- Eric
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
On Jan 16, 2005, at 6:58, Chris Thomas wrote:
A key question might be: how far along is Allan with the syntax highlighting rewrite?
Certainly not where I'd like to be with it :/ Also, my primary priority is to give maximum flexibility to this system, a GUI editor is unlikely to appear right away (but I'll make sure that syntaxes can be reloaded etc. from within the editor, and a general bundle-editor is going to debut in next beta, probably available in 2-3 days) -- I'd say to Nick, if you like to program, do go ahead and see what you can do!
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' [...]
Great idea! Certainly this should be the case. So far I'd relied on the context of the element to narrow down the scope of the styles applied. But this is much better.
So basically there are two hierarchies, the context hierarchy which is reached using CSS-inspired notation, and then the actual element name, which is a dot-separated hierarchy.
I don't know what to do exactly with function names and other elements that use part of a keyword match ("foregroundColor[2]").
What I have in mind is naming the captures using a new key, e.g.:
{ name = function; match = "defun ([a-zA-Z][a-zA-Z0-9_]*)\s*\(.*\)"; captureNames = { 1 = "name"; 2 = "arguments"; }; }
Since 'name' and 'arguments' are not a children of 'function' I initially thought that it should be reached with something like 'function#name'. So 'function' is the entire match, and 'function#name' is only the name part.
However, I'd like to allow for the actual value (of e.g. name) to be something that one can test when targeting the element, e.g.:
{ name = tag; begin = '<(.*?)'; end = ...; captureNames = { 1 = "name"; }; ...; };
And then apply styles like this: tag[name=strong] { fontStyle: bold; } tag[name=em] { fontStyle: italic; } tag[name=u] { fontStyle: underline; }
But I'm still considering implementation details for this one.
Sorry if this seems rambling, long day...
Not at all, very good post! :)
On Jan 16, 2005, at 7:48, Allan Odgaard wrote:
And then apply styles like this: tag[name=strong] { fontStyle: bold; } tag[name=em] { fontStyle: italic; } tag[name=u] { fontStyle: underline; }
Actually, this should go a bit further. Implicitly there would be #element, #content, etc. So in fact one would use:
tag[name=strong]#content { fontStyle: bold; }
So that only the content of the element would be in bold.
On Jan 16, 2005, at 7:53, Allan Odgaard wrote:
tag[name=strong]#content { fontStyle: bold; } So that only the content of the element would be in bold.
P.S. I will read up on CSS and XPath syntax before settling for a syntax -- me thinks it's best to use a (subset) of something existing rather than invent my own stuff ;)
On 16/01/2005, at 12:36 PM, Eric Hsu wrote:
(1) bundle writers standardized the 'names' of the various color classes and
The whole syntax highlighting thing is going to be overhauled, so in my opinion, it will be a bit a waste of time... The SH files will all have to be re-written or updated soon, so I don't see the need to do it twice or more, but if you've got lots of time on your hands, go for it ;)
Also, FWIW, it's very hard to standardize the names. For example the Ruby SH mentions many 'classes' that are not applicable in PHP whatsoever, and vice-versa.
I *think* Allan is moving towards "official" language definitions (maintained centrally), and then a syntax *styling* interface which will essentially provide the power to edit the colours and font styles of the elements define in the language definition.
My advice is "sit tight, and wait for the good things to come", but of course, I am just one man :)
--- Justin French, Indent.com.au justin.french@indent.com.au Web Application Development & Graphic Design
-
Allan Odgaard -
Chris Thomas -
Eric Hsu -
Justin French