[TxMt] elusive key bindings & UI confusion

[Allan Odgaard]

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  
> than to

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  
ahead! :)

> 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
> or
> 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 that would  
> 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.