I appreciate cmd-T as a more flexible replacement for old-school keyboard buffer switchers like the traditional Emacs c-x b action. However, one of the most critical uses of c-x b, in my experience, is the ability to instantly toggle between the last 2 buffers in the current window/pane, which cmd-T (and the stationary ordering of the tabs, as compared to something like the stack ordering of the File History dropdown in XCode editor panes) cannot accomplish.
I understand that certain special cases of toggling, like switching between matching, identically-named header and implementation files can be accomplished with special commands and that toggling can be achieved by manually reordering tabs in such a way that the desired 2 files are adjacent in the tab list, but this misses the deeper point that toggling between the last 2 files -- no matter how they were reached, what their file name relationship is, or where they fall in the tab list -- is one of the most central and frequently performed actions at least in my programming experience. (And it is, of course, all the more critical without split pane support ;).
It seems to me, however, that this can be addressed quite simply and elegantly in the context of the current cmd-T system. All that would have to happen is that the first item in the list would always default to the last active tab when the window is first opened. Given that the list ordering is dynamic and adaptive, á la Quicksilver, it hardly seems that this very subtle reordering would present any sort of usability issue or confusion. Of course, how this most-recently-used item might be prioritized in the list after the user starts typing, if at all, is an open question, but one which need not even be answered a first version (the behavior can perfectly reasonably be just as it is now after the first search letter is typed).
The general issue of fast toggling and navigation between files also brings up a small related thing I've been wanting to see for some time:
I would love to have the ability to re-order tabs using the keyboard, alone -- just something akin to select next/previous tab, but which moved the current tab right/left.
That's it for now. Back to the code. -jrk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
[x] me, too!
great idea Jonathan!
tom
On Aug 10, 2005, at 1:00 AM, Jonathan Ragan-Kelley wrote:
I appreciate cmd-T as a more flexible replacement for old-school keyboard buffer switchers like the traditional Emacs c-x b action. However, one of the most critical uses of c-x b, in my experience, is the ability to instantly toggle between the last 2 buffers in the current window/pane, which cmd-T (and the stationary ordering of the tabs, as compared to something like the stack ordering of the File History dropdown in XCode editor panes) cannot accomplish.
I understand that certain special cases of toggling, like switching between matching, identically-named header and implementation files can be accomplished with special commands and that toggling can be achieved by manually reordering tabs in such a way that the desired 2 files are adjacent in the tab list, but this misses the deeper point that toggling between the last 2 files -- no matter how they were reached, what their file name relationship is, or where they fall in the tab list -- is one of the most central and frequently performed actions at least in my programming experience. (And it is, of course, all the more critical without split pane support ;).
It seems to me, however, that this can be addressed quite simply and elegantly in the context of the current cmd-T system. All that would have to happen is that the first item in the list would always default to the last active tab when the window is first opened. Given that the list ordering is dynamic and adaptive, á la Quicksilver, it hardly seems that this very subtle reordering would present any sort of usability issue or confusion. Of course, how this most-recently-used item might be prioritized in the list after the user starts typing, if at all, is an open question, but one which need not even be answered a first version (the behavior can perfectly reasonably be just as it is now after the first search letter is typed).
The general issue of fast toggling and navigation between files also brings up a small related thing I've been wanting to see for some time:
I would love to have the ability to re-order tabs using the keyboard, alone -- just something akin to select next/previous tab, but which moved the current tab right/left.
That's it for now. Back to the code. -jrk ______________________________________________________________________ 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
- -- Tom Lazar http://tomster.org
On Aug 9, 2005, at 6:06 PM, Tom Lazar wrote:
[x] me, too!
He actually means M-x set-variable -> me-too -> t
:-)
-- Brian Lalor / blalor@bravo5.org Notmeflex (nŏt mē´ flěks) n. The involuntary act of hitting the brakes when you see a cop, regardless of whether you're speeding or not.
On 10/08/2005, at 1.00, Jonathan Ragan-Kelley wrote:
[...] but this misses the deeper point that toggling between the last 2 files
If I'm in file A I use cmd-T to open file B, when done, I press cmd- W, and I'm back to A, if I need B again, I do cmd-T and return (which is already on B). If I need to go back and forth a lot, I use the option-cmd left/right of course.
It seems to me, however, that this can be addressed quite simply and elegantly in the context of the current cmd-T system. All that would have to happen is that the first item in the list would always default to the last active tab when the window is first opened.
I've changed it so that w/o a filtering string, it sorts items based on last time used.
I don't clear the filter string when pressing cmd-T -- but with your usage, you'd probably just have it cleared most of the time anyway.
[...] I've been wanting to see for some time [...] ability to re- order tabs using the keyboard
And it has been on the to-do for some time -- but all this project stuff is really scheduled for 1.2.
If I'm in file A I use cmd-T to open file B, when done, I press cmd-W, and I'm back to A, if I need B again, I do cmd-T and return (which is already on B).
The problem I have with this is the asymmetry of the action. It forces me to think about which half of the toggle I'm on, rather than just doing it without thinking.
If I need to go back and forth a lot, I use the option-cmd left/right of course.
And the problem with this is that it breaks down if I leave more than 1 or 2 files open at a time, since then the file to which I'm switching probably already has a tab open which may well not be adjacent to the previous file. This is precisely what motivated the mention of keyboard control for reordering tabs, though I think in all truth I'm just not much of a tabs person in general, outside my browser, and ultimately (when plugins materialize and I can just write my own buffer switcher, if necessary) I may want to disable the tabs altogether (blasphemy!).
I've changed it so that w/o a filtering string, it sorts items based on last time used.
Do you mean it's already in 1.1b16 or that you just changed it in development? It doesn't seem to me to be doing that in b16, so I trust that's not what you meant (though I may have misunderstood how it works)...
I don't clear the filter string when pressing cmd-T -- but with your usage, you'd probably just have it cleared most of the time anyway.
Well, I still like to be able to choose files explicitly this way, as well, but it's definitely a huge start. Since you leave the previous filter string selected on pressing cmd-T it's pretty trivial to just hit delete, so, since the exact usage of this window is of course a matter of personal preference, I'll leave further exploration of its subtleties to future discussion and reflection.
And it has been on the to-do for some time -- but all this project stuff is really scheduled for 1.2.
Rock on. I don't mean to prod you unnecessarily with any of this, it's just the reality of spending >8 hours/day working in an app that, as polished as it is, one always thinks of a plethora of tweaks and enhancements in the course of a day's work. I just spam the list whenever one of these thoughts develops into a more clear form, so the flurry of requests and ideas at any given moment is in no way meant to be urgent or demanding. And your phenomenal responsiveness certainly doesn't discourage frequent suggestions ;) -jrk
On 10/08/2005, at 2.53, Jonathan Ragan-Kelley wrote:
I've changed it so that w/o a filtering string, it sorts items based on last time used.
Do you mean it's already in 1.1b16 [...]
No, in such case I'd have said which version and phrased it as a question to why that behavior didn't already fulfill the request! ;)
On Aug 10, 2005, at 2:53 AM, Jonathan Ragan-Kelley wrote:
I don't mean to prod you unnecessarily with any of this, it's just the reality of spending >8 hours/day working in an app that, as polished as it is, one always thinks of a plethora of tweaks and enhancements in the course of a day's work. I just spam the list whenever one of these thoughts develops into a more clear form, so the flurry of requests and ideas at any given moment is in no way meant to be urgent or demanding.
once again, i agree fully. to me, certainly, your input comes across as constructive and not as nagging. i also second your opinions on the asymmetry of allan's "opening and closing" scenario and regarding the "non-adjacentness" of most files. while i'm currently back to only using TM <2hrs/day I do know what you mean ;-)
best regards,
tom -- Tom Lazar http://tomster.org
-
Allan Odgaard -
Brian Lalor -
Jonathan Ragan-Kelley -
Tom Lazar