On 7 Jul 2006, at 14:20, Allan Odgaard wrote:

...

Thinking mainly about the items in the css & scripts folders within there, but even other items. I've tried my own local copy inside ~/Library/Application Support/TextMate/Support/ and every permutation of that, but no success.

Starting with last build it now looks at Support/version and picks the folder with the highest version.

So if you want to have a local override, you need to ensure that the version is higher than the one shipped with TM. Keeping the local copy updated (via svn) will ensure that.

Well, I apologise IF I don't get this correctly, but the above does NOT seem to solve my issue. Put simply it's like this:

The default TM Support .css file has black text on white background.

IF I would like this to be Red text on a green background (not really, just example) then my version should over-ride the default.

The above seem to indicate that I should just have another copy of the Support stuff from the SVN locally, and that needs to be updated on a regular basis in order to stay ahead of your version in the app. It would also seem to mean that I would have to inflict my version of the .css on everyone else, just to have the version that I like.

Did I get that correctly ? IF so, then a much better version would be to look for the local Support dir / file and IF found then use that, else use the default version regardless of version number or anything like it.

Just my 2 pence.

Kind regards,

Mats

---- "TextMate, coding with an incredible sense of joy and ease" - www.macromates.com -

On 8/7/2006, at 13:16, Mats Persson wrote:

[...] The above seem to indicate that I should just have another copy of the Support stuff from the SVN locally, and that needs to be updated on a regular basis in order to stay ahead of your version in the app. It would also seem to mean that I would have to inflict my version of the .css on everyone else, just to have the version that I like.

Why would your local changes have to be inflicted on others?

Did I get that correctly ? IF so, then a much better version would be to look for the local Support dir / file and IF found then use that, else use the default version regardless of version number or anything like it.

I don’t fully understand -- are you saying you don’t want TM to respect the newly introduced version file, so that you can have local changes w/o having to ensure that the files you haven’t modified are up-to-date?

The last month(s) has seen dozens of support questions from people who had an old support folder but bundles which relied on the latest version -- thus I introduced this version number.

I reckon what you’re really after is moving CSS out of the support folder and make a separate system to deal with CSS customizations. Currently though a lot of bundles ship with their own CSS, so I don’t know how much would actually be gained from that.

If the CSS was factored out, there is however still the problem with versioning and keeping up-to-date. E.g. the Status command in the Subversion bundle is currently going through major stylistic changes -- if anyone had a local version of the Subversions CSS folder which eclipsed the default one, he would probably get a rather screwy visual result when he got the new command (but not CSS.)