On Dec 30, 2004, at 1:06, Charles Miller wrote:

Both Safari (cmd-opt-w) and IDEA have "close all tabs except the current one", which I find frequently useful.

That I can add.

On 30. dec 2004, at 3:32, Lang Riley wrote:

Allan,

I would prefer a "close current file" option from the right-clickable context menu for the currently open file. It would be very clean and nice.

Nothing wrong with both :-p. I too use the close all keep current in Safari from time to time.

On Dec 30, 2004, at 12:01, Ivar Åsell wrote:

On a side-note that command usually(?) means "Close All" instead of "Close One". At least that's how I'm used to the command (from finder).

Currently TextMate has Close All Tabs on control-cmd-w. Mainly because option-cmd-w was already taken for Toggle Soft Wrap.

I've never mentioned this, but my convention was to (for most of it) use option-cmd for toggling of options (W/L/B for soft Wrap/Line numbers/Bookmarks) and ctrl-option-cmd for 'toggling' windows (S/M/C for Snippets/Macros/Commands editor, P for web Preview, V for clipboard history, D for project Drawer etc.).

And personally I place the majority of my custom stuff (macros, commands) on control-shift. I should probably change the Delete Line macro to use that as well, so to not conflict with forward delete.

In the same vein I should remove all default option key bindings :) For the records, I took option-L/W/P from TextExtras by Mike Ferris, who is now with Apple AFAIK! ;)

Justin Henry wrote:

Allan Odgaard wrote:

...

On Dec 29, 2004, at 6:55, Lang Riley wrote:

...

Is it possible to close files that are open in tabs that are not visible, i.e., located in the tab overflow without disturbing tabbed files that are visible?

No, not apart from the Close All Tabs. I'm not sure how I should allow for this? Maybe a qualifier while selecting the item in the overflow menu (similar to other alternative menu items), but I don't know if this would actually be a used feature!?!

I think it would be much more helpful if one could expand the tab bar and have the tabs "wrap":

http://jdhenry.com/tm-wrap-tabs.png

This way the files in the tab overflow would be accessible via the tab bar. Adjusting the height of the tab bar (i.e. by dragging the bottom of it) would affect the number of tabs visible - those not able to fit would still go into the overflow.

Looks good Justin. What would happen when a tab from the top row was selected? Would the selected tab's row jump to the bottom?

(I'm thinking about the consistency of the tab metaphor, and the highlighted tab being 'attached' to the document)

drew.

Ryan Schmidt wrote:

On 01.01.2005, at 21:15, Drew McLellan wrote:

...

Justin Henry wrote:

...

I think it would be much more helpful if one could expand the tab bar and have the tabs "wrap": http://jdhenry.com/tm-wrap-tabs.png This way the files in the tab overflow would be accessible via the tab bar. Adjusting the height of the tab bar (i.e. by dragging the bottom of it) would affect the number of tabs visible - those not able to fit would still go into the overflow.

Looks good Justin. What would happen when a tab from the top row was selected? Would the selected tab's row jump to the bottom?

(I'm thinking about the consistency of the tab metaphor, and the highlighted tab being 'attached' to the document)

Yes - I'm thinking specifically of how UltraEdit for Windows works, where the tab row containing the selected tab jumps down. This way the tabs stay in order within their row.

That would be how Windows does it, and I personally find it infuriating. It's bad user interface design. Interface elements should not jump about.

Multirow tabs are also bad interface design, which is why Apple's operating systems don't support it or do it. If they weren't tabs but instead pushbuttons then it might be ok. (I'm thinking of OS X's square toggle buttons here.)

Are you referring to something in the HIG?

Introducing multirow tabs would not necesarily directly impact all users - by default, it would be set to not wrap (just one row would be displayed), and excess tabs would dump into the overflow, just as it does now. If a user wanted to see more of their tabs, they could choose to expand the tab bar to the number of rows of their choice by dragging down the bottom of the bar.

The point of having tabs, at least in this application, is to provide you with easier and quicker access to the files you are currently working on.

I find that once the file goes off of the tab bar and into the overflow list, going back to that file isn't that much easier than looking through the project drawer - especially if I am working on a decent number of files. This kind of defeats the purpose of having my files available to me in tabs at the top of the window.

-Justin

Although I dislike the fact that I don't see what it is open in the single-row model, I like how Eclipse resolves this: There's a shortcut (Apple-E) that expands the list of wrapped tabs. In that box there's a handy textfield that filters as you type (on the fly) and has the keyboard focus.

This way I can switch quickly with a few keystrokes. Of course you can do that with the mouse but that's rather slow compared to the keyboard in this case because in addition to move the hand out ouf the keyboard *you* have to search for the filename in a probably long list of choices.

I recorded a movie to depict the sequence, there Apple-E is typed to make the yellow box pop up:

http://www.hashref.com/textmate/eclipse_tabs.mov

-- fxn

After some times using TM now, I realize I almost never use tabs. When I work on a project I end up with so many tabs that it's much more easy to select the files in the drawer, even if I have to expand folders first. So I don't really see how having to type to find a tab would make it easier...

Maybe I'm missing something, but, what is the advantage of tabs over project's drawer? Who really use tabs over drawer for big projects and why?

I can see something like 50 files at the sale time in the drawer, while I rarely see more than 10 tabs at once.

One thing that could be improved in the drawer, IMO (and makes it definitely replace tabs for me):

Now when you navigate thru files in the drawer with up and down arrows, you have to hit Return to open the file (even Enter don't work). Wouldn't it be better if the files were opened as soon as they are selected? I don't know what are the HIG guidelines on that, but when I select mails with arrows in Mail.app the mails are opened directly.

Now you can have a file opened while the selected file in the drawer is another one and the tab of the opened file is hidden, the only place where you can see the name of the file you're working on is the title bar. This is a bit confusing, IMHO.

I love tabs in a lot os apps, but I can't really see the point in TM. Sorry if I miss something.

-- Fred

On 2 janv. 05, at 20:51, Allan Odgaard wrote:

On Jan 2, 2005, at 3:45, Xavier Noria wrote:

...

[...] a shortcut (Apple-E) that expands the list of wrapped tabs. In that box there's a handy textfield that filters as you type [...] you can do that with the mouse but that's rather slow compared to the keyboard [...]

Yes, I would like to introduce something similar to this. I rarely touch my mouse when I'm using TM, so I'm definitely a fan of improving switching tabs via the keyboard :)

---

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

i often work with pretty bloated projects, and the tabs don't really work for me, either. my personal preference would be for a list of active files displayed in the drawer - so split the drawer between that and the project file list, as shown in this mockup:

http://dev.samandrews.com/misc/tm1.jpg (121k jpg)

to further extend the functionality of this view, it might be desirable to indicate some basic metadata for open files such as last saved, number of bookmarks (useful if you use bookmarks to track your to-do items) and so forth. i think the spotlight-esque filter as xavier proposed could also be very useful.

perhaps the option to display file like this could be toggled as a preference at a per-project level, or automatically implement itself when there are too many tabs (although i think that could be a pretty confusing user experience).

Allan Odgaard wrote:

On Jan 2, 2005, at 3:45, Xavier Noria wrote:

...

[...] a shortcut (Apple-E) that expands the list of wrapped tabs. In that box there's a handy textfield that filters as you type [...] you can do that with the mouse but that's rather slow compared to the keyboard [...]

Yes, I would like to introduce something similar to this. I rarely touch my mouse when I'm using TM, so I'm definitely a fan of improving switching tabs via the keyboard :)

---

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

On 4. jan 2005, at 10:55, Sam Andrews wrote:

as an example; for simple web projects, i will often want to work on either php files or template (.tpl) files. so when i open a file in a project tm should automagically assign it to my "php" or my "template" smart group.

Another possibility is to have different file types in different directories. I usually do that anyway to keep things properly separated.

Oh and... please take just a few seconds to not quote ALL of the email you are replying to. It's highly confusing. Especially the 600 signatures left at the bottom.

Here's my two cent's worth of input.

On 4 Jan 2005, at 09:35, Sam Andrews wrote:

i often work with pretty bloated projects, and the tabs don't really work for me, either. my personal preference would be for a list of active files displayed in the drawer - so split the drawer between that and the project file list, as shown in this mockup: http://dev.samandrews.com/misc/tm1.jpg (121k jpg)

Sam, please accept my apologies as it's not personal, but I have to pass on the following comment to your proposal.

Allan, I sincerely beg you - on my knees, hands firmly clasped - to PLEASE NOT implement anything like that in TM. It reeks of BBEdit, and is in my mind a completely flawed implementation.

A far better improvement on the current implementation would - in my mind at least - be a larger sized overflow ">>" tab at the end of the bar to handle the overflow files. The size of this tab should be of dynamic size to fill the space between the last normal tab and the end of window, and big enough to display the same widgets & text as a normal tab, but also a [ N ] (number of files in tab).

On selecting the tab - via mouse or keyboard - a pop-down tab menu would appear, with the standard tab layout ( ie close widget + file name). Using the normal tab navigation key commands, would highlight the selected file in the pop-down menu, and then the top tab text would display the active file name. Think HTML Select pop-up menu functionality.

If you wish to move a file from the overflow tab, then you would just move it as a normal tab, and the last normal tab in the existing tab bar moves into the overflow tab. (Hope you followed me there ? )

While I'm at it. How difficult would it be to implement the following: Apple+Alt+Shift+ <left/right arrow> to actually move the order of tabs via the keyboard ???

To me that solves much of the problems, as the overflow tabs follow the same functionality as normal tabs. Love to hear your views.

On 2 Jan 2005, at 19:55, Allan Odgaard wrote:

So a group is configured how? And should it be possible to do ad hoc grouping by e.g. dropping one tab on another tab (to make it into a group), and exactly how does a group affect navigation?

I too like the idea of group based tabs, where all .css files were stored in one single tab and so on, but I can't see how that implementation would work any better than the current implementation. What happens when you select a file in a group tab, does it take over the visibility of that tab, or open in a new tab ?? How would you navigate this group tab scenario with the keyboard ??

On 4 Jan 2005, at 06:53, Allan Odgaard wrote:

Tabs allow me to quickly navigate in this hot set with keys (the visual aspect of them is negligible), and I can re-arrange them to have two files I often switch between next to each other. Locating the file in the project drawer is probably 1-5 seconds compared to 0.1-0.8 seconds switching to it using cmd-option left/right.

Absolutely! Tabs rocks, and it is the way to go. No doubt!!

My hot set is rarely >5 and my TextMate project contains >100 sources alone. And the drawer is certainly more work to use.

I too close down unused files as soon as I've stopped working on them, as it's relatively quick and easy to open them up again when needed. But I guess we are dealing with personal habits & 'discipline' here.

Kind regards,

Mats

A few further points:

And No, Sam, I'm not in a vendetta against you. : )

On 4 Jan 2005, at 11:11, Sam Andrews wrote:

disadvantages of too may tabs:

• several keystrokes/mouseclicks to reach hidden tab

Keystrokes: This will be the case with every implementation I can think of, so I can see no advantage in your proposed design / file list.

Mouse clicks: In a BBEdit like list, I guess we could easily click on the chosen file (tab), but we could do the same with my implementation idea. Think folder of bookmarks in Safari bookmarks bar. Click-hold and select file/bookmark.

• we must shift focus to new tab (thereby hiding other tabs)

Might be misunderstanding you here, but isn't that the case anyway ? Alternatively, this could (??) be a preferences option that would indicate how to handle the overflow-tab click event, display selected overflow file or not.

• most tab-bar solutions (ie, drop-down menus) are counter-intuitive

because filenames are still hidden from the user's view - so they can't comprehend at a glance whether the tab they want is available or not

I don't know about your screen, but I've got a lot more horizontal space than I have vertical. (iMac 20"), and I am already toggling folders in the Project Drawer, so I can't see how I - or anyone - could possibly fit in open files and file hierarchy into the Project Drawer. It's a UI disaster in my mind.

As for a single glance view of open files. Normal tabs shows clearly, so we just need the overflow tab to work better than current implementation. Perhaps we could have Apple+Alt+[plus/equals] to display the overflow-tabs menu ? If you use the mouse, then you can just click on the tab and see all open files within it.

advantages of file-list:

• keeps usual keyboard nav, but requires less mouseclicks

Not getting this point at all, but a file list is no easier to click through than tabs. Might require less mouse movement, but that's it.

• "spotlight" filter could be applied to *all* open files

Sledgehammer and nut comes to mind with regards to 'spotlight-ing' open files. If you need to search your open files, then you have too many open.

As for 'spotlighting' / smart groups in the Project Drawer, well, that's a different issue.

As Allan is well aware of, the Project Drawer could be improved in various areas, and will be for 1.2 (??) Perhaps a better way to display open files for some, would be - as I believe has been proposed before - discretely background-highlighting opened files in the Project Drawer. (sort of like current file icon changes on un-saved files now). That ought to give a better alternative to those that don't like the tabs.

On 4 Jan 2005, at 16:37, Allan Odgaard wrote in response to Wayne Larsen:

...

I agree with this. I am amazed at (and impressed by!) those of you who only work with several files at one time

Clearly this must be task-dependent. The distinction is not really open files for me but more like 'active' files.

So for the next hour or so, I'll have these 5 files “open” and forget about the rest of the project (which contains hundreds of files in a hierarchical structure).

As a general point on the number of open files, which is really at the root of this 'problem'/thread.

I guess we all have our different ways of working and I may not understand the structure of everyone's work, but I would still hazard the guess, that most developers only work on 1-5 related files at any given time. I have found that I too end up with a lot of open files, but have started to learn the process of doing the work required in the file and then closing it down. I can always open it from the Project Drawer within 1-5 seconds, and trust me, I spend a lot more time thinking about the code I am about to write than I spend on re-opening files, so a saving of N seconds here or there is really a mosquito fart in outer space.

The thing about TM is that as you work with the program and it's inherent limitations you can reform your working practices, often for the better. I and many others 'complained' about the lack of code-hinting for our chosen language - and it would still be good sometimes - but now I have created a largish collection of snippets that does my work much quicker and better than any other code-hinting solution I'm aware of. Hell, I've even rolled my own basic CVS functionality into TM. (will share later this week when I'm sure everything is OK for public consumption)

Kind regards,

Mats

On Jan 5, 2005, at 8:50 PM, Allan Odgaard wrote:

On Jan 4, 2005, at 20:30, Mats Persson wrote:

...

...

• "spotlight" filter could be applied to *all* open files

Sledgehammer and nut comes to mind with regards to 'spotlight-ing' open files. If you need to search your open files, then you have too many open.

For those interested in trying this sledgehammer, there is a b1p2 available: http://macromates.com/textmate/files/TextMate_1.1b1p2.zip (the feature is in Navigation / Go to File… or command-T).

Great! Both the textfield and the scope selector will be very useful. I like specially the possibility of opening a file that way project-wide, which is not very common in editors AFAICT. Most of the time I know the name of the file I want to switch to so that's really cool. Thank you Allan!

What could be done to distinguish files with the same name in the file list? Appending their directory relative to the project root to their right could be a solution.

-- fxn

haven't played with it yet (and won't for a little while), but does it support shell-like completion of filenames using tab? if not, i could see that being very useful for finding files in deep paths.

Xavier Noria wrote:

On Jan 5, 2005, at 8:50 PM, Allan Odgaard wrote:

...

On Jan 4, 2005, at 20:30, Mats Persson wrote:

...

...

• "spotlight" filter could be applied to *all* open files

Sledgehammer and nut comes to mind with regards to 'spotlight-ing' open files. If you need to search your open files, then you have too many open.

For those interested in trying this sledgehammer, there is a b1p2 available: http://macromates.com/textmate/files/TextMate_1.1b1p2.zip (the feature is in Navigation / Go to File… or command-T).

Great! Both the textfield and the scope selector will be very useful. I like specially the possibility of opening a file that way project-wide, which is not very common in editors AFAICT. Most of the time I know the name of the file I want to switch to so that's really cool. Thank you Allan!

What could be done to distinguish files with the same name in the file list? Appending their directory relative to the project root to their right could be a solution.

-- fxn ______________________________________________________________________ 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

On Jan 6, 2005, at 1:35 AM, Fred B. wrote:

-Your Command+T shortcut made me think about tabs in other apps. Again, this is only a question: Why not implement tabs in TM as in Safari, FireFox, iTerm, etc. ? I mean, opening a new tab for newly opened files only if requested (or stated in prefs). Like: I open a file in a project => it goes in the current tab. I Command-open a file => it goes in a new tab. Command+T makes a new empty tab. etc.

I would __really__ like this behavior. It would be far more useful to me than the current TM implementation. Just make it work like Safari, with the same tab behavior, history tracking, etc. Safari is easily the most efficient tab implementation I use on my Mac. Like other posters, the current TM implementation is pretty much worthless because of the current new-tab-for-every-single-file-in-my-project-and-there-are-hundreds-and- I-end-up-using-the-project-drawer-because-the-tab-I-want-is-never- visible--even-if-I-just-used-it-two-seconds-ago approach. ;-)

Best, Eric

BTW, I use TM for Ruby/Rails development.

On 6. jan 2005, at 10:35, Fred B. wrote:

Hi Allan, [...a lot of comments, then a lot of other mails in a mess of signatures etc...]

Please stop bottom- and top-quoting :-p. It's very confusing. Quote relavant parts, then your comments below. Sorry for bitching ;-).

On Jan 4, 2005, at 10:35 AM, Sam Andrews wrote:

i often work with pretty bloated projects, and the tabs don't really work for me, either. my personal preference would be for a list of active files displayed in the drawer - so split the drawer between that and the project file list, as shown in this mockup:

http://dev.samandrews.com/misc/tm1.jpg (121k jpg)

to further extend the functionality of this view, it might be desirable to indicate some basic metadata for open files such as last saved, number of bookmarks (useful if you use bookmarks to track your to-do items) and so forth. i think the spotlight-esque filter as xavier proposed could also be very useful.

I second that proposal. In my daily experience the one row of tabs (both in TextMate and Eclipse) just adds noise because you have just a handful of opened files there, whereas I tipically have a lot more. Because of that the tab selector is in fact useless most of the time, and the interface it enforces makes looking for an opened file not in the tabs something exceptional, I mean, it is not the default interface, the easy one, but it is the one I normally need.

I recognize nevertheless that tab reordering and the tabs themselves have been in the promotion of TextMate from the start. The Eclipse interface (that want I sent in a movie) could be seen as an evolution of the current interface, and the list in the drawer with metadata could be seen as a new feature. By now I don't know how I'd introduce that new feature in a coherent way though.

-- fxn

Since I've argued before that the tab bar is not effective for my style of working, I should add my support to some of these ideas.

...

On Jan 4, 2005, at 10:35 AM, Sam Andrews wrote:

In my daily experience the one row of tabs (both in TextMate and Eclipse) just adds noise because you have just a handful of opened files there, whereas I tipically have a lot more. Because of that the tab selector is in fact useless most of the time, and the interface it enforces makes looking for an opened file not in the tabs something exceptional, I mean, it is not the default interface, the easy one, but it is the one I normally need.

This is my experience for my usage patterns.

On 4-Jan-05, at 5:28 AM, Xavier Noria wrote:

If I think further I believe the distinction between opened files and files in the project is artificial. It is a traditional distinction, but tradition sometimes can be improved as iTunes did.

I agree with this. I am amazed at (and impressed by!) those of you who only work with several files at one time, and know that you are finished with a file and are able to close it. Obviously I have far less foresight in my work patterns -- I don't want my editor to force me to have to manage these details.

I think there have been several excellent ideas proposed in this thread. The spotlight filtered textfield is a very strong idea. Emacs has a buffer search with filename completion that provides much of this functionality. As proposed in this thread with proper ui feedback, this would be very powerful.

Grouping related files into a single tab is an interesting idea, however, I'm not convinced that the effort to create and maintain these groups, and the ui required to differentiate between members of a tab group and shortcuts between them would make the idea really effective.

At the risk of repeatedly banging the same drum, I also believe that working history is also a useful way to switch between files. Having a keyboard shortcut to page between files in the order they have been opened would allow one to quickly switch between files in a working set in an ad hoc fashion.

The most useful combination, imo then would be: * Project Drawer * History List * Spotlight Like filtered search

Whether you retain the tab bar as is, add a file list view, eliminate the tab bar completely, or some other proposal does not matter-- this would be a minor detail since that visual feedback provided by the tabs would not be necessary.

Regards, Wayne

On 04-01-2005 10:35, Sam Andrews wrote:

i often work with pretty bloated projects, and the tabs don't really work for me, either. my personal preference would be for a list of active files displayed in the drawer - so split the drawer between that and the project file list, as shown in this mockup:

http://dev.samandrews.com/misc/tm1.jpg (121k jpg)

Looks pretty good, I like the idea.

Jeroen.

On Jan 1, 2005, at 23:27, Tobias Luetke wrote:

Since we are talking about the tab bar once again, I'd just like to bring up the topic of tab groups. For Visual Studio 6 you can get the wonderful tab bar extension which supports grouping of header / source in just one tab as seen here:

http://www.wndtabs.com/wt/tour/tab_parts2.gif

The idea sounds interesting, but that screenshot doesn't sell it very well ;)

Something configurable along those lines in textmate would be absolute *killer*. For example in an MVC framework like rails you could group controller/view or even model/unit test into an group.

So a group is configured how? And should it be possible to do ad hoc grouping by e.g. dropping one tab on another tab (to make it into a group), and exactly how does a group affect navigation? Should it then be option-cmd-left/right to move to prev/next group, and option-cmd-up/down to move around in the group (and if there are files in the project that belongs to the group, these are added if they are not already there)?