Trevor Harmon wrote:

On Sep 8, 2008, at 6:53 PM, Thomas Allen wrote:

Yes.

What is it that you like, exactly? Would you also prefer your web browser to work the same way? (i.e., every click of a link opens it in a new tab)

I don't know Thomas's reasoning, but I can tell you why I prefer the current method. In a browser, most of the time when I click a link it means I'm done with the current page and want a new one. In an editor, opening a file does not mean I'm done with the old one. I almost certainly plan to return to it. So, the two apps each do the correct thing "most of the time". The browser re-uses the tab, and the editor opens a new one.

One situation never occurs in a browser but is very, very common in an editor: What happens when you have unsaved changes in the current file then open a new file in the same tab? Should the editor auto-save the current file? Discard changes? Ask the user? None of those approaches are very satisfying.

Some editors have separate concepts of "window" and "buffer". The buffer contains a file. The window displays a buffer. You may have active buffers that aren't displayed, or you may have multiple windows displaying a single buffer. In those editors it's not so bad to load a new file into the existing window. The old file is still there in its own buffer, it's just no longer being displayed. TextMate doesn't follow that paradigm, though. TextMate has a one-to-one correspondence between the window (tab) and the file. I assume that changing that paradigm would mean a huge code change.

I do think that TextMate needs a way to somehow scroll the tabs in a manner similar to Firefox. Not being able to see and re-arrange tabs to the right of the viewport is really annoying. Yes, TextMate's tab handling is the same as Safari's and probably follows the Apple UI guidelines, but it's awkward. Firefox's technique of being able to scroll the tab bar left and right is much easier to use when many tabs are open.