Your comments

Seems like ST is not using HFS's Catalog Node ID (or CNID) ..
> 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:
Now if one'd image such a overlay with all of ST's buffers (grouped by view) that'd be quite nice..

> 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 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)

Count me in.. being used to jEdits flexible splitting features the prefab layouts of ST2 feel a bit restraining.

However there's another catch to ST2's way of handling the view/buffer management which feels somewhat tedious: the need to shove buffers from one view to another.. in jEdit any buffer is automatically available in any new split(view) you create.. which is fast and handy. Combined with bufferswitchers (see my topic here) the whole buffer/view managament is both more flexible and faster in everyday usage imho. Dunno about the way VIM does it, but in jEdit you can:
  • split horizontally
  • split vertically
  • unsplit current
  • unsplit all
  • restore split
plus of course you can view/edit a buffer in any number of splits.. pretty handy more often than not. ;)

My 2¢ on the ideas mentioned in this thread:

1. Too many files in open recent list
  • number of files should be a user pref
  • seperating files and dirs: +1
  • showing sidebar/goto files should be user pref

2. Integration with OSX
  • makes sense: +1
3. Readability
  • Showing only filenames is useless.. once you have multiple identicaly named files you loose: -1 on that idea. The proposed "show path on key-combo" becomes a nuisance if you generally work on lots of identicaly named files.. so no real help but rather a needless slowdown.. my proposal to suit all needs: a user pref which switches between "allways show path" and "only show path on key-combo"
  • path readability: the current left to right state is rather hard to read, even if you'd bolden the filename and grey-downed the path.. since most of us are left-to right oriented readers, the main info (filename) should be aligned to the left, and additional info (path) following right to it.. but that's an easy fix: either just reverse the path, or place the filename first and let the path follow seperately (and bolden/gray-down as icing on the cake if you wish..)
  • Showing Icons: makes sense.. that way you can visually preselect before you need to actually read any filename.. +1
Hi Joel.. yes, you're right.. i'll post a seperate topic on the split/view/group management.
+1.. same here: diffing a lot in jEdit.. one of the reasons i'm still with that ugly b*tch of an editor.. ;)