I would like to automate some customization for some bundles (as colors), is the format in those .plist files standard (for instance Perl.plist)? If it is and you wanted to search for a parser for some programming language which keyword would you use?
If you are asking whether the 'names' of each color class (e.g. Comments) in the .plist is standard across the bundles, I'd say it would be a miracle if they were, since they were all hacked by individuals who wanted their favorite language colored.
On the other hand, it might be possible for people to agree to use keywords in their names so the XML could be parsed and the color settings could be custom set by a big regexp search and replace.
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
TM bundles generally have more colors than that. But if Bundle writers could agree on a reasonable base set and rename their names, that could go a long way towards making the colors customizable before Allan gets his next solution done.
Allan may have to set standards like this anyway, unless he writes a small GUI Syntax File browser that displays the Names with a little Color Picker patch. That would be fabulous, of course.
- Eric
On Jan 4, 2005, at 8:59 PM, Eric Hsu wrote:
I would like to automate some customization for some bundles (as colors), is the format in those .plist files standard (for instance Perl.plist)? If it is and you wanted to search for a parser for some programming language which keyword would you use?
If you are asking whether the 'names' of each color class (e.g. Comments) in the .plist is standard across the bundles, I'd say it would be a miracle if they were, since they were all hacked by individuals who wanted their favorite language colored.
Well not. Since names are clearly free as in
name = "q() quotes, line start"
my idea was to inspect the .plists I want to customise, hard-code those literals in a config file of my own, and use a parser to modify them by hand. So it's a rather dirty solution to ease maintenance until some generic coloring schema is provided by TextMate itself.
I asked whether a parser exists before I write some even more dirty hack because if for zero price I could robustly deal with the elements of, say,
{ name = "q() quotes, line start"; begin = "^q[qwx]*\("; end = "\)"; patterns = ( { match = "(\<(.*)\>)"; foregroundColor = "#009933";} ); },
that could be better. Otherwise I'll write something ad-hoc.
-- fxn
On Jan 4, 2005, at 20:59, Eric Hsu wrote:
[...] if Bundle writers could agree on a reasonable base set and rename their names, that could go a long way towards making the colors customizable before Allan gets his next solution done.
Also for the next solution this will be required. At least to have colors apply to multiple files. The idea is that for a given color a CSS-like selector is given to describe which elements should have this color. So that could be “Comments, 'C++ Comments'” or “HTML > PHP Comments" (the first would match all elements Comments or 'C++ Comments' where the latter would match all Comments in HTML-embedded PHP).
Allan may have to set standards like this anyway, unless he writes a small GUI Syntax File browser that displays the Names with a little Color Picker patch. That would be fabulous, of course.
Actually, I did/do consider having each bundle/syntax include an example source that uses all matched language constructs. The user would then just click a portion of this example (showed by TM) and TM would tell the name/path of the construct to which the user could associate styles/settings.
On Jan 4, 2005, at 21:10, Xavier Noria wrote:
I asked whether a parser exists before I write some even more dirty hack because if for zero price I could robustly deal with the elements of, say,
Ah yes -- this is the standard old-style ASCII property list format. You can convert it to XML like this: plutil -convert xml1 <file>
TextMate still understands the XML version, and this may be easier for you to work with. Basically the file is just a serialized array/dictionary (hash). OS X itself have parsers for this format, but if you convert it to XML you can use any XML parser to read them (using OS X has the advantage that it will build the structure in memory).
Which language do you want to write it in?
On Jan 4, 2005, at 9:17 PM, Allan Odgaard wrote:
On Jan 4, 2005, at 21:10, Xavier Noria wrote:
I asked whether a parser exists before I write some even more dirty hack because if for zero price I could robustly deal with the elements of, say,
Ah yes -- this is the standard old-style ASCII property list format. You can convert it to XML like this: plutil -convert xml1 <file>
Ahhh, excellent thank you.
TextMate still understands the XML version, and this may be easier for you to work with. Basically the file is just a serialized array/dictionary (hash). OS X itself have parsers for this format, but if you convert it to XML you can use any XML parser to read them (using OS X has the advantage that it will build the structure in memory).
Which language do you want to write it in?
In Perl or Python preferably. The XML solution via plutil looks like the easiest, but for curiosity how would you deal with the structure in memory without an intermediate XML file? If there was something in Cocoa to deal directly with that format maybe I could play a bit with PyObjC maybe.
-- fxn
On Jan 4, 2005, at 21:39, Xavier Noria wrote:
Which language do you want to write it in?
In Perl or Python preferably. The XML solution via plutil looks like the easiest, but for curiosity how would you deal with the structure in memory without an intermediate XML file? If there was something in Cocoa to deal directly with that format maybe I could play a bit with PyObjC maybe.
There is, NSDictionary (which is a hash/associative array) can load its values using the dictionaryWithContentsOfFile: selector/method.
So in Objective-C that would be: id dict = [NSDictionary dictionaryWithContentsOfFile:syntaxFile];
And now dict is an associative array representing the contents of the syntaxFile. E.g. you'd access patterns, which is an array and each element is again a dictionary (which may have patterns again)...
On Jan 4, 2005, at 10:04 PM, Allan Odgaard wrote:
On Jan 4, 2005, at 21:39, Xavier Noria wrote:
Which language do you want to write it in?
In Perl or Python preferably. The XML solution via plutil looks like the easiest, but for curiosity how would you deal with the structure in memory without an intermediate XML file? If there was something in Cocoa to deal directly with that format maybe I could play a bit with PyObjC maybe.
There is, NSDictionary (which is a hash/associative array) can load its values using the dictionaryWithContentsOfFile: selector/method.
So in Objective-C that would be: id dict = [NSDictionary dictionaryWithContentsOfFile:syntaxFile];
And now dict is an associative array representing the contents of the syntaxFile. E.g. you'd access patterns, which is an array and each element is again a dictionary (which may have patterns again)...
Magnific, with that class this is far easier than I expected.
I have not generalised the script yet, but since it is gonna be something very targeted to what I want to be useful to others anyway, here it goes the starting point which is really simple if you know just a bit of Python. After installing PyObjC[*] this properly modifies a property list (I did the trials with the one for Perl):
<mockup>
#!/usr/bin/python
from Foundation import NSMutableDictionary
fg = "foregroundColor"
perl = u"/path/to/your/Perl.tmbundle/Syntaxes/Perl.plist" plist = NSMutableDictionary.dictionaryWithContentsOfFile_(perl) for p in plist['patterns']: name = p['name'] if name == "Control Structures": del p['fontStyle'] p[fg] = "#881950" if name == "Reserved Words": del p['fontStyle'] p[fg] = "#000000" # ...
plist.writeToFile_atomically_(perl, 1)
</mockup>
Really, that's all.
That needs you to inspect the .plist for the names you are interested in. Just printing the plist variable after its creation works like a charm and formats the structure for easy reading:
print plist
In fact, as you see, you have there a clean interface to redefine the entire .plist as you wish.
For Perl there's CamelBones[**], which I have not tried yet but looks like the task would be as easy.
Great!
-- fxn
[*] http://pyobjc.sourceforge.net/ [**] http://camelbones.sourceforge.net/index.php
On Wed, Jan 05, 2005 at 07:46:24AM +0100, Xavier Noria wrote:
I have not generalised the script yet, but since it is gonna be something very targeted to what I want to be useful to others anyway, here it goes the starting point which is really simple if you know just a bit of Python. After installing PyObjC[*] this properly modifies a property list (I did the trials with the one for Perl):
And while I am one of those that thinks *every* Mac should have PyObjC installed :-), you can also use Python's Mac standard library plistlib to avoid the dependency.
#!/usr/bin/python
from Foundation import NSMutableDictionary
fg = "foregroundColor"
perl = u"/path/to/your/Perl.tmbundle/Syntaxes/Perl.plist" plist = NSMutableDictionary.dictionaryWithContentsOfFile_(perl)
from plistlib import Plist
perl = u"/path/to/your/Perl.tmbundle/Syntaxes/Perl.plist" plist = Plist.fromFile(perl) ... plist.write(perl)
On Jan 5, 2005, at 1:46 AM, Xavier Noria wrote:
Magnific, with that class this is far easier than I expected.
Isn't Python beautiful? :-)
I have not generalised the script yet, but since it is gonna be something very targeted to what I want to be useful to others anyway, here it goes the starting point which is really simple if you know just a bit of Python. After installing PyObjC[*] this properly modifies a property list (I did the trials with the one for Perl):
This really is cool. I'm envisioning a script that could work on any plist to redefine the fonts and colors based on a predefined mapping. This is somewhat more difficult given the nesting of patterns that TM uses, but still should be do-able...
For Perl there's CamelBones[**], which I have not tried yet but looks like the task would be as easy.
Don't kid yourself. What's easy in Python is ugly, dirty and nasty in Perl. But the same can be said about anything written in Perl. ;-)
On Jan 5, 2005, at 4:25 AM, Jim Tittsler wrote:
And while I am one of those that thinks *every* Mac should have PyObjC installed :-), you can also use Python's Mac standard library plistlib to avoid the dependency.
This seems to require that the .plist be in the XML format. :-(
-
Allan Odgaard -
Brian Lalor -
Eric Hsu -
Jim Tittsler -
Xavier Noria