As I slowly customise TextMate by altering the bundles in ~/Library/Application Support/TextMate, I'm wondering what happens when TextMate is updated with alterations to the default snippets, macros & commands?
To get the benefit of such bundle updates am I going to have to manually edit my bundles in the above location to include the extras in the new bundles? Or do the bundles in the actual application package have effect to the extent that individual elements therein have not been overriden by anything in the user's Library/Application Support directory?
I hope this question is clear...
bongoman
On 10/10-2004, at 0:24, bongoman wrote:
As I slowly customise TextMate by altering the bundles in ~/Library/Application Support/TextMate, I'm wondering what happens when TextMate is updated with alterations to the default snippets, macros & commands? To get the benefit of such bundle updates am I going to have to manually edit my bundles in the above location to include the extras in the new bundles? Or do the bundles in the actual application package have effect to the extent that individual elements therein have not been overriden by anything in the user's Library/Application Support directory?
I am pretty sure that, at the moment, bundles override each other on a per-name basis, so new features won't automatically come in to play. I think that will change in the future though, but it is not clear what the prefered method would be. Any thoughts?
I am pretty sure that, at the moment, bundles override each other on a per-name basis, so new features won't automatically come in to play. I think that will change in the future though, but it is not clear what the prefered method would be. Any thoughts?
Cascading syntax definitions could be quite useful, but comes with added complexity; cascading and precedence becomes usability issues, and must be added with care.
sadly, I can´t think of any viable solution at this point. :)
On Sun, 10 Oct 2004 12:38:03 +0200, Hans Petter Eikemo hpeikemo@gmail.com wrote:
sadly, I can´t think of any viable solution at this point. :)
I'm not really looking forward to having to update my ~/Library/Application Support TM bundles with any new stuff from the application package bundles for each & every point release of Textmate and yet that's what it seems we'll have to do.
bongoman
On 10. Oct 2004, at 13:18, bongoman wrote:
sadly, I can´t think of any viable solution at this point. :)
I'm not really looking forward to having to update my ~/Library/Application Support TM bundles with any new stuff from the application package bundles for each & every point release of Textmate and yet that's what it seems we'll have to do.
I don't think it's as bad as you predict. It's not like you'll make a copy of all default bundles, change a lot of things, and then we'll likewise change a lot of things in the default for the next release, and somehow you want our changes and keep your own as well!?!
I think I'm convinced that I'll separate styles from rules _before_ I do the syntax-makeover, so hopefully that should soon cure the need for having "normal users" modify the syntaxes (to change the visuals).
Also, if you have e.g. a default HTML bundle and you make a local HTML bundle, it'll overshadow the default stuff on a per directory-basis. So if you only make macros in your local copy, it'll only be the macros directory you'll need to update if you want some of the new defaults.
Kind regards Allan
Also, if you have e.g. a default HTML bundle and you make a local HTML bundle, it'll overshadow the default stuff on a per directory-basis. So if you only make macros in your local copy, it'll only be the macros directory you'll need to update if you want some of the new defaults.
One idea is to have a basedOn (or derivedFrom) parameter in the syntax definition, so Syntax named PHP can change when HTML changes, because of its defined dependency.
sort of like a IsA to the include parameter´s HasA
Initially was thinking only that syntaxes with same name would cascade. But use of inheritance will be more clear, as an accurate hierarchy is defined.
-
Allan Odgaard -
bongoman -
Hans Petter Eikemo -
Sune Foldager