In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
In contrast, web browser tabs operate quite differently. They're manual instead of automatic: A new tab doesn't open unless you explicitly open one. Until then, new data is displayed in the current tab. TextMate's tab feature would be much more useful to me if it worked this way --- the way web browsers do.
Does anyone prefer the current (automatic) behavior?
Trevor
Yes.
Trevor Harmon wrote:
In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
In contrast, web browser tabs operate quite differently. They're manual instead of automatic: A new tab doesn't open unless you explicitly open one. Until then, new data is displayed in the current tab. TextMate's tab feature would be much more useful to me if it worked this way --- the way web browsers do.
Does anyone prefer the current (automatic) behavior?
Trevor
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 2008-September-09 , at 00:53 , Thomas Allen wrote:
Trevor Harmon wrote:
In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
In contrast, web browser tabs operate quite differently. They're manual instead of automatic: A new tab doesn't open unless you explicitly open one. Until then, new data is displayed in the current tab. TextMate's tab feature would be much more useful to me if it worked this way --- the way web browsers do.
Does anyone prefer the current (automatic) behavior?
I would prefer the one you propose only if there is a very easy way yo open a document in a new tab (i.e. middle click or option click on the file name in the drawer). The mouse interactions would be easy to copy from browser but I don't see an obvious solution when opening files with ⌘T, or jumping to the header file from an implementation file.
JiHO --- http://jo.irisson.free.fr/
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.
On Sep 9, 2008, at 11:13 AM, Steve King wrote:
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.
That's a good point, although I think a satisfying way to handle this is simply to open a new tab if the current one is unsaved.
Even though I see now why some people prefer the always-a-new-tab behavior, I still think there are legitimate reasons for manual tabs as well. It would be nice if this were an option, then everyone could just choose the setting they like best.
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.
I was thinking it might be cool if TextMate had visual tabs like OmniWeb or Shiira:
http://www.mathgamehouse.com/images/phillryu/shiira2full.png
But after testing the idea I've decided it just doesn't work with text. Web pages with graphics can be distinguished at thumbnail size, but source code files can't.
Trevor
On 2008-Sep-9, at 11:13 AM, Steve King wrote:
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.
Exactly. The web is basically read-only, so replacing one page with another in a window is fairly safe. Not so with local files.
The UI for "too many tabs to fit the window" is definitely problematic, but that would be true no matter what method was used to open those tabs, would it not? I prefer the current behavior for *creating* tabs, but would like to see a better way to *manage* large numbers of them.
It sounds like you want to alter a perfectly functional UI in the hopes of avoiding a less-than-functional one somewhere else. That seems backwards to me. Why not focus on the real problem so we don't have to worry about how many tabs we end up with?
--- Rob McBroom http://www.skurfer.com/
A web browser has a back button. I wouldn't want a back button in my editor because I'd lose my changes. I generally don't like using bn and bp in Vim (buffer next and previous), and prefer splits + tabs.
Also, webpages aren't editable, so the dynamic is different.
Thomas
2008/9/9 Trevor Harmon trevor@vocaro.com
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)
Trevor
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
I think that an interesting alternative would be to show the open buffers in a drawer. This could be shared with the file browser or openable on the other side of the window.
2008/9/9 Thomas Allen thomasmallen@gmail.com
A web browser has a back button. I wouldn't want a back button in my editor because I'd lose my changes. I generally don't like using bn and bp in Vim (buffer next and previous), and prefer splits + tabs.
Also, webpages aren't editable, so the dynamic is different.
Thomas
2008/9/9 Trevor Harmon trevor@vocaro.com
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)
Trevor
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Mon, Sep 8, 2008 at 6:16 PM, Trevor Harmon trevor@vocaro.com wrote:
In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
In contrast, web browser tabs operate quite differently. They're manual instead of automatic: A new tab doesn't open unless you explicitly open one. Until then, new data is displayed in the current tab. TextMate's tab feature would be much more useful to me if it worked this way --- the way web browsers do.
Does anyone prefer the current (automatic) behavior?
I think that I'd prefer the current behavior with a slight change.
If instead of putting a newly opened tab at the end of the list (and therefore out of sight if too many tabs are open) what if TM put the most recently viewed tab at the head of the list, keeping the tabs in MRUish order rather than LROish (least recently opened), order.
Trevor Harmon wrote:
In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
In contrast, web browser tabs operate quite differently. They're manual instead of automatic: A new tab doesn't open unless you explicitly open one. Until then, new data is displayed in the current tab. TextMate's tab feature would be much more useful to me if it worked this way --- the way web browsers do.
Does anyone prefer the current (automatic) behavior?
Actually, what I *really* prefer is ridiculously complicated. Eclipse has a plugin called Mylyn (formerly Mylar). It's a "task-focused UI"; it keeps track of which files you like to open while working on a certain todo, bug, etc. Then, when you switch tasks, it opens the appropriate set of files in tabs. If you open more than a certain number at once, it starts closing older tabs, I think with an LRU algorithm. (It may even get smart about noticing that you reopened a file it just closed; I forget.) It also highlights the most-accessed files in the file drawer, so it's easier to find the files you'll use most often.
It sounds like way too much cleverness, but it actually works well. Short of that, I don't think I'd want TextMate to start replacing the current file with a different one in the project.
In a web browser, I don't often enter URLs, or choose them from a list; I'm going to them as part of a browsing sequence. I'm rarely working depth-first, or going back and forth between two pages, so the "same tab" default makes sense. Lots of times, I'm following a trail - this page comes up in a search result, and it's not what I want, but it links to another page that has a similar discussion, which references a Wikipedia article with the answer.
In a text editor, I rarely look through a bunch of files by opening them, navigating to the "right file"; I go directly there. So if I open a second file, it means I'm going to want to work with both files.
I think you might find a good UI by following the browser concept - overload a command-click or shift-click or whatever in the project drawer to mean "open in new tab" (or "open in same tab" if you set some preference that reverses the sense, the way Firefox can).
Trevor
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Sep 8, 2008, at 5:16 PM, Trevor Harmon wrote:
In TextMate, buffer tabs are automatic: A new tab is always opened whenever you click on a file in a project drawer. After a half hour of navigating source code, I suddenly find dozens of tabs open at the top of my editor window, but I can only see a few of them. This makes the tabs feature basically unusable.
You might try Ciaran Walsh's QuickLook in TextMate and TextMate in QuickLook plugins (http://ciaranwal.sh/2007/11/15/quicklook-and- textmate). With these installed, you can click on a file in the project drawer, and, using the QuickLook item from the contextual menu, open the file in QuickLook. It will still be rendered using TextMate as an engine (if you install the latter plugin), and, after you're done with it, you're not left with an open tab.
-- Phil
-
Jay Levitt -
jiho -
Phil Schumm -
Rick DeNatale -
Rob McBroom -
Steve King -
Thomas Allen -
Trevor Harmon