On Jun 14, 2005, at 3:52, Ben Parzybok wrote:
I'm trying to resolve a key conflict (command-b
used to wrap the
selection in bold. Now it tries to build in Xcode)
and I'm wondering if there's a better way to try to resolve this
Well, for this particular key, it was “decided” that cmd-B should do
a build, so cmd-B is used for several different commands (that all do
builds for misc. languages), and so, it's not recommended to use that
key for custom stuff -- of course, if you don't care about this, go
1) go to /Library/Application Support/Textmate
and delete bundles I don't use
2) pour through everything in the bundle editor looking for command-b
3) just give the html command-b snippet better scope.
As for #2 you can use Show Keybindings from the Language Definition
bundle, and as for #1 you can disable bundles via Change Filtering…
in the bundle editor.
Giving your own command a better scope would probably be a good
solution, seeing how cmd-B is currently overloaded for text.latex,
source.java, and source. So you'd have to delete/disable 3 bundles/
commands. And more commands using cmd-B may appear in the future
(though for specific scopes, so probably won't clash with your stuff).
Outside of the php the command works fine
It's the “generic” build command that has scope set to source. So
anything more specific than just source, or anything not containing
source (as e.g. text.html) will win over this build command.
I haven't been in the bundle editor lately, so
I'm guessing the new
xcode key binding is from a bundle update or an install of the
latest beta. This strikes me as tricky behavior. Is the bundle
editor a straw house that I'll need to fine tune regularly?
Not exactly sure what a straw house refers to (in the figurative sense).
Hopefully it shouldn't be necessary to care about bundle items for
other languages than those you use yourself when bundles are updated,
because these items should limit their activation method to the scope
of the language. Xcode build of course being the exception ;)
However, if you open the bundle editor, click the Change Filtering…
and disable all but the bundles you use, you won't see any updates to
all the disabled bundles in the future, and so, these shouldn't
interfere with your custom stuff.
TextMate is feeling complicated to me these days, at
least for the
work that I do (php/css/html/mysql/js). I'm not sure if it's
because I'm unused to the new bundle architecture, that I'm using
the latest betas, or it really is complicated. But it's gotten to
the point that I'd like to bring up the topic. Perhaps TextMate is
moving toward more of a higher end development tool -- I see a lot
of latex (which I believe is a type of paint...) and other
languages that are not so front-end web developer-ish, and if so
then that's how it is. I would be sad, however. I can see how it's
getting tremendously more powerful...it's just trying to keep up
that appears difficult.
I'm not sure if it's the actual UI of the bundle editor you find
complicated, or the amount of (default) stuff in the bundle editor?
As for the latter, Mats suggested that TM should ship with only a
couple of languages enabled by default, and then let the View ->
Language have a “More languages…” option that'd take the user
directly to the filtering prefernce.
Such an approach might help, although the motivation for pursuing
this is mainly that some do not find that TM actually do support
their language (because it's disabled by default).
As for the structure of it all, it does bother me slightly that a new
user unfamiliar with the bundles concept might find it strange that
90% of the functionality is buried deep down in the Automation
submenus, but I'm not sure how to better layout all that stuff.
One possible solution is to have a (gasp) Setup Wizard
allow someone to select which languages they use, and to simplify
the bundle editor,etc, based on that.
Sometime in the future bundles should be selected like e.g.
Quicksilver plugins -- but I'm not sure how you'd adjust the bundle
editor to the installed bundles. The GUI is currently very minimal.
What might help would be if each bundle item had a “second page” with
item specific documentation. Although it doesn't sound like this is
what you're seeking.