+6

alternative to tabs: bufferswitcher w. filepath

jeandeluxe hace 12 años actualizado por aristidesfl hace 12 años 9
preface: i'm a fairly die hard jEdit user.. it's a ugly duck with a lot of rough edges, _but_ does have some powerfull features that keep me sticking to it.. However these days i discovered ST2, and it does so many things right out of the box, that i'd be switchin in an instance if it weren't for a few crucial topics ... In this post i'd like to address the views(groups)/buffer management:

In ST2 i don't know what exact file i'm editing unless i hover over the tab and wait for the tooltip to popup.. while in generall the tabs do show the file's path, it allways is truncated - with some sense though - but in the end gone completely once a certain number of tabs accumulate.. and over the day these "whereami-hovers" become really cumbersome.

Here's how jEdit handles this: the standard buffer chooser is a select that spans the top of the edit-area showing the full path of the current file.. looks like so (yess, jEdit _is_ ugly ;) : http://dl.dropbox.com/u/10220684/screenshots/screenshot%202012-04-15%20um%2013.48.02.PNG

Imho these bufferwitchers are clearly supperior to any kind of tab.. you simply know where you are without any interaction needed. And of course switching buffers becomes easier and faster as well: you know where you will switch to (or have switched to if by key-command) right away..

So: how about such bufferswitchers as alternative to tabs? ;)

extended sidenote: there're two more distinct differences how jEdit handles the buffer/view management: For one there are no predefined layouts(groups).. you just split views whichever way you need to by a simple keystroke.. or revert splits as easily one by one, or all at once. The other difference: you don't have to shove buffers around by hand.. all buffers are immediately available in any split you create.. you just choose the buffer you want to view in the given split and that's it.. of course: you can also view a single file in any number of splits at once.

thx 4 listening.. ;)
Jan
+1 for both ideas. Might want to split them into separate UserEcho issues though so people can vote for either or both.
Hi Joel.. yes, you're right.. i'll post a seperate topic on the split/view/group management.
I agree. Tabs are an inferior solution in the sense they bring real world limitations into a virtual environment. They are good for the everyday user in the same way a virtual calculator in shape of calculator is a pleasant metaphor, until the day it becomes a pain to click the buttons and a text field where you can enter the math expression seems like a good idea.


I stopped using tabs in sublime (they are hidden) in favor of a combination of "Goto Anything..." + "next_view_in_stack/prev_view_in_stack". 

The only 2 things missing are: 

1. The name of the file being displayed. Would be nice to have an option to display the current file name in the status bar.

2. When browsing the views in the stack, a representation of the views, and an indicator of witch view is currently being displayed (pretty much like the application switcher in Windows, Ubuntu(alt+tab) or Mac OS X(cmd+tab)). This could be achieved with a palette containing the views in the stack, which gets dismissed when the modifier key (cmd/alt/ctrl) of the shortcut set to "next_view_in_stack/prev_view_in_stack"  is released. http://sublimetext.userecho.com/topic/106652-/


Separate topics for issues nr.
1. http://sublimetext.userecho.com/topic/106652-/
2. http://sublimetext.userecho.com/topic/106653-/
> I stopped using tabs in sublime (they are hidden) in favor of a combination of "Goto
> Anything..." + "next_view_in_stack/prev_view_in_stack".

just for comparison: with bufferswitchers that'd be either a single key-combo to cycle through the buffers (up & down), or alernatively choosing directly via the select by mouse..

> 1. The name of the file ..in the status bar.

Limited imho.. mainly: you can only identify one file at a time and need to shift the buffer focus just to see another file. Not least: though a minor issue at first glance, but a GUI should provide "short ways" in getting things done (or presenting information).. the menu bar is on the top anyway, and if you work on file, your focus will typically be somwhere at the top of that file.. so the status bar is "far away" in these terms.

> 2. .. This could be achieved with a palette..

I'd imagine this a nice addition to bufferswitchers.. a modifier which expands the select and thus becomes a palette showing you all avail. files where you can either choose by mouse or by cycling up/down via cursor keys (or some combo)

cheers,
Jan
1. it only makes sense to have the name in the status bar, obviously when there is no menu bar (in fullscreen mode) 
> 1. ...obviously when there is no menu bar (in fullscreen mode)

I'm still thinking bufferswitchers.. which this thread is about. If those were implemented, there'd be no need for the status bar.. no matter how many views and no matter if fullscreen or not. Of course if one opts for no tabs/bufferswitchers at all, there's not much left besides the status bar.. there you have a point.

However your idea about something alike the app switcher panel is nice too.. dunno if you're OSXish, but maybe you know Witch: it's kinda app switcher on steroids, displaying all windows grouped by app: http://dl.dropbox.com/u/10220684/screenshots/witch_panel.png
Now if one'd image such a overlay with all of ST's buffers (grouped by view) that'd be quite nice..

cheers,
Jan
I used witch for a while, specially to hop thru windows of the same app, but I dropped it eventually because the the default switcher looks better and takes no extra RAM. And I use mostly launchbar any way to change apps (much like Goto Anything in sublime).

I guess I'm in favor of bufferswitchers, as long as they look better then in jEdit ahah