On Feb 8, 2006, at 2:41 PM, porneL wrote:

I second these opinions. Macro menu is tiny, smaller than less used language and tab size choosers.

true, but they need to show their information. What information does the macro menu need to show?

And if that wasn't enough I additionally have to maneuver through submenus - when TM's window is very near bottom of screen (I have dock on side) current language's submenu isn't under cursor and sometimes it's not even immediately visible!

IMHO it should be much larger, and maybe there should be two buttons - one with macros for current context/language *only* and another with all the submenus.

Do people really use the mouse to navigate this menu? I just press control-esc, then the first two letters of the bundle I want, then right arrow, left arrow if I want to go back and so on. Plus, by default when you pop the menu up, it's in the current language, so you don't need to start typing. So for me the size of the button doesn't really matter.

-- regards, porneL

Haris

For me the problem isn't the accessibility of the menu items : as you stated, you can use the keyboard to navigate the actions menu, you can also use the keyboard shortcuts and the mouse.

The problem is that the process of learning (memorizing) the dozens of commands, snippets and macros is hard because TM doesn't do much to help you.

Suggestion: You could tear off a submenu of the gear popup, and make it a floating palette, so you can keep an eye on the list of snippets, commands and macros of the language (bundle) you're currently working in. Seeing them on the side of the screen for some time would help to memorize them.

2006/2/8, Niels noggin@mac.com:

Do people really use the mouse to navigate this menu? I just press control-esc, then the first two letters of the bundle I want, then right arrow, left arrow if I want to go back and so on. Plus, by default when you pop the menu up, it's in the current language, so you don't need to start typing. So for me the size of the button doesn't really matter.

I just noticed that this suggestion is mentioned several times on the wiki: http://macromates.com/wiki/Suggestions/GUI (see the contributions of John Lianoglou and Sascha Brossmann)

2006/2/8, Charilaos Skiadas cskiadas@uchicago.edu:

On Feb 8, 2006, at 3:44 PM, Ned Baldessin wrote:

...

Suggestion: You could tear off a submenu of the gear popup, and make it a floating palette, so you can keep an eye on the list of snippets, commands and macros of the language (bundle) you're currently working in. Seeing them on the side of the screen for some time would help to memorize them.

Ah, that is indeed a nice idea. I usually keep the Bundle editor open for those purposes, but having an optional floating window with the commands from a bundle, together with short descriptions of what each command does, would be ideal. I am guessing that could possibly be a plugin? I don't know.

On 2/8/06, Ned Baldessin androse@gmail.com wrote:

I remember when getting started with TM, what strike me was that most of the functionality was buried into the Macros, Snippets and Commands menus. Those three menus seemed extremely dense, and the rest of the menus, and the app in general, seemed very "easy", or light.

Up to this day, I still haven't fully explored the potential of those menus, because I get the feeling that they change all the time.

Adding the "gear" pop up menu at the bottom of the window was great. Are there other ways to "de-densify" all that functionality, and "smooth en" the learning curve ?

One obvious but perhaps heretical possibility would be to place that bar at the top of the window by default, with an option to place it at the bottom.

pb

-- Paul Bissex http://e-scribe.com/news/ Northampton MA USA 01061-0847

"Density" is a very nice generic description of the problem!

By the way, in the following, I don't at all mean to be harsh! Instead, I'd like to figure out how "what's in there" can be made even more visible, available and understandable... to get even more converts. TextMate is a fabulous product and, rather then "upgrade" BBEdit, I recently purchased TextMate instead.

Critique...

The functionality and power of TextMate is unevenly distributed in its visual working space. (Even more difficult, much of it is, in fact, NOT visible at all.)

It is difficult to "discover" previously unknown functionality. It is also difficult to RE-discover ("remember") previously discovered functionality.

Furthermore, the way that "I" mentally "clump" functionality often is not the way it is clumped in TextMate. For example... I remember that I can do something. But is it a built-in feature, or in a macro, command or snippet? (Oh! I just noticed: apparently, the "gear" icon combines access to all three?)

What was it called? ? And, was it... THIS keyboard shortcut? YIKES! Hmm... well, that's actually sort of interesting. I wonder what I did?

If it's a built-in feature, is it under the "Edit" menu, or perhaps the "Text" menu? If not found in the "Text" menu, maybe it's in the Automation > Replay Macro > Text menu. OR, Automation > Insert Snippet > Text. OR... Automation > Run Command > Text. Or maybe the "gear" menu. [Too bad my keyboard binding for that shortcut doesn't work!] Oops, well I guess (think) not. Hmm... maybe it's under the "Edit" menu? ;)

!!

I have a horrible urge to shout for the inclusion of Toolbars (Multiple! and Fully Configurable! Of course.) And Floating Palettes. LOTS of floating palettes. All, also (of course) Fully Configurable. Lots of drag, drop, stretch and perforate. And a Unified Keyboard-Shorcut/Keybinding Editing & debugging Panel. Also... well, Fully Configurable.

OK, my tone is somewhat flippant. But seriously, in TextMate there is "more than meets the eye." How do we bring that to the surface and make it more coherent and accessible? Without dynamiting the fish pond.

By which I mean that implementing "A Palette for Every Function and a Function for Every Palette" (or something) will simply smother the existing interface. Bringing "everything to the surface" (that's the dynamite in the fishpond) is not a good solution.

Over-stuffed drop-down menus begat hierarchal menus. Overstuffed hierarchal menus begat "tear off" menus (palettes). Overstuffed palettes begat "tabbed" palettes. Then the tabbed palettes grew their OWN hierarchal ("flyout") menus and I'm afraid we've come full circle! I don't know where the heck "tool bars" and "gutter bars" got into the picture. :) Now we've got scrolling, collapsing sidebars (has anyone looked at Adobe Lightroom?) And don't forget "twirl-down" menus. Hierarchal, but instead of popping out, they reveal their contents (like the "reveal" triangle in the Mac Finder). I'm skeptical that ANY of this makes functionality any more accessible or discoverable than if it was simply dumped into a gigantic "bubble" that users could simply re-arrange to their own liking. Rather like a "desktop" in this case.

Hmm! Maybe we need a "Dashboard-like" feature!! Press a button and your editing interface switches to a completely customizable "TextMate Dashboard" interface. Users get to scatter WHATEVER they want anywhere on this alternative "desktop/control surface/utility panel/macro switchboard"... whatever you want to call it. Why should "Preferences" or the bundle editor be constrained a dialog box? Why not give it an entire new view into the application?

Users can organize commands, macros, snippets ... WHATever, here in any way they like. All the (and any of the) CLUTTER would (here) be constrained to the TextMate "Dashboard," leaving the editing interface sleek and tidy! Oh! I'm liking this. Excuse me for a moment while I duck out and grab a patent or two.

OK, I'm back. Maybe the TMDB ("TextMateDashBoard") has a terminal window sitting ready to type into. Maybe it also has that wished-for SFTP window. Maybe ... ?? Maybe there can be more than one TextMate "screen set," "virtual desktop" or "dashboard." ??

Well, I don't have a lot of answers to this problem right now [Oh, yes I do! Look at that "dashboard" idea! ;) ].

I want [some of] the benefits of toolbars and palettes, but not the added clutter of them. And since the user community currently has to rely pretty much on a single programmer in this, I would not want Allan spend most of his energy programming Palette Behavior. Ugh.

eo

On Feb 8, 2006, at 6:21 AM, Ned Baldessin wrote:

I remember when getting started with TM, what strike me was that most of the functionality was buried into the Macros, Snippets and Commands menus. Those three menus seemed extremely dense, and the rest of the menus, and the app in general, seemed very "easy", or light.

Up to this day, I still haven't fully explored the potential of those menus, because I get the feeling that they change all the time.

Adding the "gear" pop up menu at the bottom of the window was great. Are there other ways to "de-densify" all that functionality, and "smooth en" the learning curve ?

…just thinking out loud.

Cheers.

2006/2/8, Nicholas Cole nicholas.cole@gmail.com: Dear List,

One of the most striking things to a new user is that the most important part of the UI for textmate is a button a that is at the _base_ of the window (v. unexpected) and that is the smallest part of the UI. I'm quite sure I would not have realised its significance had I not seen the Screencasts, and I know that people I've recently introduced to Textmate have had the same problem. Is there any way it could be made more obvious?

Best,

N.

On 9 Feb 2006, at 07:22, Brad Choate wrote:

We already have Cmd+T and Cmd+Shift+T for search-as-you-type for files in a project and symbols in a file. I'd love a key that would present a search window for searching through bundle command/ snippets/macros. It would search as you type and would display any available shortcut key on the right to help jog your memory.

I have probably misunderstood, what Brad wants. We already have ctrl- alt-command k which will pull up the keyboard shortcut list. Did you want something other than that?

Best, Mark

_________________ Mark Eli Kalderon Department of Philosophy University College London Gower Street London WC1E 6BT

Dept webpage: http://www.ucl.ac.uk/philosophy Personal wepage: http://www.kalderon.demon.co.uk

Imagine that the items would have the command/snippet/macro symbol in front of them to make it clear what was what.

I guess it could be hidden. When I use something, I don't care about it being a macro or a snippet or jack. I think it just adds a superfluous layer of complexity -- but that's just my idea.

And much like the go to symbol window, if more than one item has the same name, it would append the bundle name at the end to make them unique.

...while I'd like this to be the default ;)

ciao,

Domenico

Thanks for the feedback regarding the UI of bundle items.

A few notes/comments/answers to issues brought up.

As for those who spoke against palettes and utility windows: I strongly dislike these things myself, so I definitely have no plans of changing to such an approach, more like offer users the ability to compose their own.

As for making the bundle item menu dynamic, that's also something which comes up from time to time, but also something I am strongly opposed to. I use functionality from many different bundles even with the same language, dynamic menus are confusing, and it already opens at the current language’s bundle (moving it up as a tool bar item may make this more apparent, and might allow having a stand-alone button which is only a short-hand to the “current” bundle, so that one doesn't have to move the mouse a few pixels).

As mentioned, I do indeed like the “search commands/snippets/macros” idea, and the addition of arguments sounds very useful. Currently this cannot be done as a plug-in, though while long-term this is likely going to be native, I do definitely want to move to a much more “open” architecture -- exactly what I mean by that will be more apparent as it happens (hopefully).

The “confusion” surrounding the Automation sub-menus: these are likely going to be removed. I don't ever use them anymore, and I don't know why people mention that they first search these, and then the gear menu -- the gear menu is the “new” way to present bundle items, and I have kept the old mainly because of the key equivalents leading to the bundle editor, and because there is a little to be said about having everything present in the top menus (though I do diverge from this with the tab and language settings).

The Text menu do indeed overlap slightly in scope with what bundle items hould be able to do (the transformations at the top), this is because the Text menu was there from day one, where there was close to no functionality written as bundle items.

As for not being able to remember the key equivalents, I would suggest reading the conventions I try to stick to, it might make it slightly easier to remember then (although not everything is following the conventions): http://macromates.com/textmate/manual/ appendix#conventions

As to not showing key equivalents in the gear menu for commands with a scope selector that doesn't match current scope, that would be a loss to me -- ideally though, they should be grayed out, when they can not be used, but that's not possible as long as the OS renders the menus.

As to “TextMate has so much functionality that is hidden”: I would suggest reading http://macromates.com/textmate/manual/ bundles#assorted_bundles for an overview -- and I would also ask you to consider how much of Quicksilver, Path Finder, Emacs, vim, the shell (terminal), your favorite programming language, etc. that you actually use? and despite the large portion of things you might not be using in TM, how much *do* you use compared e.g. to your previous text editor? Learning to use every single feature takes a certain type of person, and more importantly, it takes time -- I do think that some people may maybe have wrong expectations about how a program should be able to transform them into a superuser that master every single feature in short time :)

With the last paragraph I do not want to imply that TextMate is perfect, far from it, but I also have absolutely no ambition that users should be able to use 90% of its feature-set -- probably more like 20% (though I am regularly surprised about how much people actually do get out of the application).

Maybe that was the wrong paragraph to end with… just to make it clear: I do certainly appreciate people brainstorming about what's wrong/can be improved with TextMate, and I enjoy reading your feedback.

On 09/02/2006, at 7:55, Eric O'Brien wrote:

"Density" is a very nice generic description of the problem!

By the way, in the following, I don't at all mean to be harsh! Instead, I'd like to figure out how "what's in there" can be made even more visible, available and understandable... to get even more converts. TextMate is a fabulous product and, rather then "upgrade" BBEdit, I recently purchased TextMate instead.

Critique...

The functionality and power of TextMate is unevenly distributed in its visual working space. (Even more difficult, much of it is, in fact, NOT visible at all.)

It is difficult to "discover" previously unknown functionality. It is also difficult to RE-discover ("remember") previously discovered functionality.

Furthermore, the way that "I" mentally "clump" functionality often is not the way it is clumped in TextMate. For example... I remember that I can do something. But is it a built-in feature, or in a macro, command or snippet? (Oh! I just noticed: apparently, the "gear" icon combines access to all three?)

What was it called? ? And, was it... THIS keyboard shortcut? YIKES! Hmm... well, that's actually sort of interesting. I wonder what I did?

I suppose it's all context-related. Am I cranking out Python code? Check out the Python section. LaTeX? Ditto. Am I working in ActionScript? Nope, I never do. As Tom Christiansen put, us human beings, we're really great at context.

If it's a built-in feature, is it under the "Edit" menu, or perhaps the "Text" menu? If not found in the "Text" menu, maybe it's in the Automation > Replay Macro > Text menu. OR, Automation > Insert Snippet > Text. OR... Automation > Run Command > Text. Or maybe the "gear" menu. [Too bad my keyboard binding for that shortcut doesn't work!] Oops, well I guess (think) not. Hmm... maybe it's under the "Edit" menu? ;)

!!

Hmm, being more of a keyoboard-oriented user (I'm a Linux switcher) I tend to use menus as cheat-sheets, not as actual command triggers. So the Command-Esc thing works fine for me... Hit it, see what's available, look-up the key combination... (and, well, make a mental note of what you'd like to add to the command and snippets list).

So the position of the menu is not a problem for me. I like clean interfaces (I hated the Emacs tool-bar).

I have a horrible urge to shout for the inclusion of Toolbars (Multiple! and Fully Configurable! Of course.) And Floating Palettes. LOTS of floating palettes. All, also (of course) Fully Configurable. Lots of drag, drop, stretch and perforate. And a Unified Keyboard-Shorcut/Keybinding Editing & debugging Panel. Also... well, Fully Configurable.

OK, my tone is somewhat flippant. But seriously, in TextMate there is "more than meets the eye." How do we bring that to the surface and make it more coherent and accessible? Without dynamiting the fish pond.

By which I mean that implementing "A Palette for Every Function and a Function for Every Palette" (or something) will simply smother the existing interface. Bringing "everything to the surface" (that's the dynamite in the fishpond) is not a good solution.

Over-stuffed drop-down menus begat hierarchal menus. Overstuffed hierarchal menus begat "tear off" menus (palettes). Overstuffed palettes begat "tabbed" palettes. Then the tabbed palettes grew their OWN hierarchal ("flyout") menus and I'm afraid we've come full circle! I don't know where the heck "tool bars" and "gutter bars" got into the picture. :) Now we've got scrolling, collapsing sidebars (has anyone looked at Adobe Lightroom?) And don't forget "twirl-down" menus. Hierarchal, but instead of popping out, they reveal their contents (like the "reveal" triangle in the Mac Finder). I'm skeptical that ANY of this makes functionality any more accessible or discoverable than if it was simply dumped into a gigantic "bubble" that users could simply re- arrange to their own liking. Rather like a "desktop" in this case.

Hmm! Maybe we need a "Dashboard-like" feature!! Press a button and your editing interface switches to a completely customizable "TextMate Dashboard" interface. Users get to scatter WHATEVER they want anywhere on this alternative "desktop/control surface/utility panel/macro switchboard"... whatever you want to call it. Why should "Preferences" or the bundle editor be constrained a dialog box? Why not give it an entire new view into the application?

Users can organize commands, macros, snippets ... WHATever, here in any way they like. All the (and any of the) CLUTTER would (here) be constrained to the TextMate "Dashboard," leaving the editing interface sleek and tidy! Oh! I'm liking this. Excuse me for a moment while I duck out and grab a patent or two.

You're describing QuickSilver. QS rocks. Absolutely. I'm off to their forums to demand a TextMate plugin. (Ouch, their site is down... nevermind).

OK, I'm back. Maybe the TMDB ("TextMateDashBoard") has a terminal window sitting ready to type into. Maybe it also has that wished- for SFTP window. Maybe ... ?? Maybe there can be more than one TextMate "screen set," "virtual desktop" or "dashboard." ??

Well, I don't have a lot of answers to this problem right now [Oh, yes I do! Look at that "dashboard" idea! ;) ].

I want [some of] the benefits of toolbars and palettes, but not the added clutter of them. And since the user community currently has to rely pretty much on a single programmer in this, I would not want Allan spend most of his energy programming Palette Behavior. Ugh.

eo

On 16/2/2006, at 21:25, Benoit Gagnon wrote:

I think the generic text editing features should NOT be implemented in a Bundle.

The great thing about moving stuff to bundles is that users can easily customize it, and bundle items have advantages such as allowing different version for different scopes and being able to trigger via various activation methods (to be extended in the future).

But of course it is also a concern that all functionality of the application moves to descendant items of the gear menu -- actually something I feared even before the 1.0: that I would end up with a “Commands” menu that had dozens of unrelated commands. I think the bundles do currently group functionality very well. But I am also considering ways to have “bundle items” appear in places currently reserved for native functionality.

Ah, boy, is QS full of surprises, or what!

Thanks ever so much for the tip: I've been looking into the Triggers section, but never thought it could be taken THAT far.

Cheers,

Kamen

With QS you can already access all menus of an application through a custom shortcut.

• Enable advanced features in QS
• Enable Proxy objects (Catalog, Quicksilver)
• Setup a keyboard shortcut under Triggers for Current Application

(Show Menu Items)

Jeroen.

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

Sean Schertell wrote:

Personally, I really don't like multi-window interfaces. Please don't clutter up textmate's beautiful one-window design with little floating palettes! ;-)

I second that.

third

fourth.