Of course, what one could do is establish hierarchy using the names, and then have the editor parse the name keys.
Yes, I believe something like this will have to be done.
From an old post:
For the record, BBEdit 8 recognizes the following colors for customization:
General: Foreground, Background Guide Contrast [the color of non-page window] Custom Highlight Color: Primary, Secondary Highlight Insertion Point Line Color Source Code: Keywords, String Constants, Comments HTML Tags: General, Processing Instructions, Anchor, Image, Names, Values
Are these enough categories to go with? Is there some common/known taxonomy of code categories we can use? If we can settle on a scheme, bundle writers can touch up their work right away.
I like the fact that TM's color schemes are so customizable; but one wonders how much complexity a typical user will want. There should probably be some kind of scheme to install the color schemes of others...
And if one sets colors in a global stylesheet, how should one handle one language embedded in another? E.g. PHP/HTML or Perl/HTML?
- Eric
On Jan 16, 2005, at 7:41, Eric Hsu wrote:
And if one sets colors in a global stylesheet, how should one handle one language embedded in another? E.g. PHP/HTML or Perl/HTML?
With only one global style sheet both languages would use the same colors. But you can target the embedded language like this:
HTML PHP strings { fgColor: blue; }
That would be 'strings' elements descendent of a PHP element descendent of a HTML element.
So there are really two hierarchies at play, and including 'perl' in the language element name (as you did) should not be necessary, since you can do: “Perl strings” instead of “strings.*.perl”.
Makes sense? Basically we have one dynamic hierarchy that is the context/location of the element (e.g. is the string child or descendent of PHP/C++/whatever) and a rather static type-hierarchy (is it 'strings.single-quoted' or 'strings.double-quoted').
-
Allan Odgaard -
Eric Hsu