Maybe a few small changes could significantly reduce the severity of the spillover problem without radically altering the current tab set-up.

One of the reasons that relatively few documents fit on the tab bar is that tabs don't get scaled down to squeeze in as many as possible (subject to a reasonable limit on how small a tab can be). By way of contrast, here is how Safari's tabs seem to behave:

  • there is a maximum allowable tab width, and a minimum allowable one
  • every tab is the same size as every other at any given time
  • tabs are scaled so that they come as close as possible to filling out the available space without spillover, but:
* if this would entail making tabs smaller than the minimum allowable width, the spillover menu appears
* if this would entail making tabs larger than the maximum allowable width, the maximum allowable width is used

If TM tabs behaved this way, many more would be visible at a time. (Ideally, the minimum and maximum tab widths could be determined by a preference, perhaps a hidden one.) For me, anyway, this would make an enormous difference.

After using the tabs for a while I've found a couple big problems:

1. After editing several files, the tab menu fills up, gets bigger than the available area, and thus loses much of its usefulness.

2. At that point, it is not possible to remove a tab that is beyond the visible area.

I think a pulldown menu, like on xcode (or the option of using one) would be a good thing.

When the tab bar overflows, an icon should appear, which opens a menu with the non-visible tabs.

You can close a non-visible tab by selecting it and use Close Tab.

But I'm looking into various alternatives for the overflow problem, like stacking, scrolling, having the last tab perform a swap etc.

-- Allan Odgaard

Perhaps an option to keep the last N files open on a tab. By the tab close (x) you could have a little lock to keep that file always on the list (and protect from close tab). btw. I can't find Close All Tabs. Would be nice to have that on the menu. -fx

With regard to having it in the menus, open the File menu and hold down the control modifier key, then it will appear.

My solution to everything is to copy EditPlus - - Tabs which take up more than one line in this case. Also, tabs should be automatic whenever a new file is open, not just for Projects.

^ please Allan, NO! Don't do that!!

I disagree with the disagreeing comment above. EditPlus is one of the most efficient editors for Windows and its functionality in this case is very good. I think it's probably a good app to look at for advice on how to handle things. -- Garrett Murray

Personally, I have no interest in tabs. In fact, i'd like to find a way to turn them off. once I have any number of files open, I prefer to just have the document drawer pop out from the side listing all documents contained. This basically gives me an unlimited listing of files that can be contained in the one editor window.

I have no idea how to build a user-experience to shift the user from a tab to drawer metaphor based on tab count though.

Wes Houghton

One thing worth considering is a "buffer list" a la emacs which would appear inside the TextMate main content area (bound to a sensible shortcut [toggle]).

For this to be useful it would need to:

  • vertically list open files (tabs)
  • allow one-key flagging of files for close, save & close, etc, with a key to execute flagged changes

I also second the idea of having an option to "autoclose the oldest tabs without unsaved changes" once they spill out of the space allocated.

David Lee

--- I have never used EditPlus, but it sounds like UltraEdit on windoze has solved this tab problem in a similar way. First of all the tabs resize; they get smaller as you add more tabs. Secondly, once the tabs reach a 'smallest' size, they spill over into a second and then third and then (n) row of tabs. I can testify that this solution really works.

When I used to use UltraEdit as my editor before i went OS X, I never had a problem with the tabs readability or accessability, and they did not have the cool feature of being able to re-order them with the mouse. Also, tabs should flash when a file is edited outside of Textmate.

For now, having many open separate windows is more efficient, as you can simply select them from the vertical list of open windows.

I would like to second the cry of "Please, NO" above. Having tabs grow into new rows, shifting your content mind you, is very UN-Mac-like. It's also NOT efficient and requires more thought, and hence more time, on the part of the user.

Before those who decry that with 'It never slowed me down!", I'd like to point out that it is a habit learned that makes you believe this. In reality, you have slowed down. Yes it may only be a fraction of a second, but those add up over time.


Why don't we just have the regular xcode functionality. You know, the little bar that shows what function/class you're in, and what file you're editing. If you click the bar on the filename, all open files are listed, letting you switch between them... Tabs are for web browsing not text editing, if you're concerned with switching files even faster just use the keyboard shortcuts and give the rest of us a nice neat menu :)

-- Ryan

How about using the tabs not directly as a way to access open files but more as a list of recently accessed files. So in that sense, it will show the same files as it presently does, but it arranges them in the order they've been accessed. (So the file being currently edited will be at the far left always, and the one next to it was the last one edited, etc.)

Personally, I've given up on using the tabs in their current implementation, it fills up too easily. Additionally, the order in which they were opened is normally arbitrary; I think their order should correspond to something intelligent. That way I can option-cmd-rcursor through my history.

-- Nick

If you want to DIY, you can disable tabs from the command line. Make sure TextMate isn't running, and then type:

defaults write com.macromates.textmate OakProjectWindowShowTabBarEnabled false

into the terminal. To bring tabs back, you'll have to:

defaults delete com.macromates.textmate OakProjectWindowShowTabBarEnabled

All ⌘T all the time! Wooo!


What I *really* miss in TM compared to Emacs (more specifically, the IDO emacs lisp extension) is the ability to select Buffers using substring matching. My coworkers usually stood by in awe while i crawled the buffer space using the keyboard. This is also my preferred method to open files (in eclipse, there is the similar but more limited ctrl-t type search). This method allows to work with an arbitrary number of buffers without even having to grab the mouse.

You can see how useful this is for history-/bookmark-URLs in the latest Firefox beta builds. If something like ido could be provided for TextMate, I would totally buy the upgrade!

UPDATE: Turns out that CMD-T is very close to what I need.


Dear macromates people, eversince I switched to Mac a few years back, Textmate was my main editor of choice. It is great. There is only one thing that bugs me: file tabs feature becomes useless when "more-than-fits" amount of tabs are opened.

Here is how it should work: 1. Tabs are always sorted from left to right by "last viewed" 2. Tabs that cannot be displayed are automatically closed. 3. More emphasis should be made on CMD-T feature to open files, where files should also be pre-sorted by "last viewed" from top to bottom. This "go to file" menu should replace the dropdown tab bar overflow menu that appears on the top right when too many tabs are opened.

Honestly, the overflow menu is harder to navigate than the actual file tree :)

Cheers! And thanks for the great product

Alexander Podgorny