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

This would allow for use of external libraries, like pyexpat used by elementtree and xml.sax parsers, without having to compile them into the builtin parser.
While it would probably mean that the interpreter wouldn't be as "clean" as sublime's, it would allow more flexibility. People would also be able to use 2.7 if they felt like it by selecting a different interpreter, living with the consequences of some potentially broken plugins.

While I like that the builtin interpreter is small and clean, I would prefer to be able to customize the modules, or versions, used by sublime. Seeing that is already the case on OS X, I believe that it has been proved to be a working solution, and should be ported to Linux as well.

File Encoding / I'm korean, but Sublime Text 2 dont support Korean file encoding( CP 949, MS949, EUC-KR ... ), so I can't use it. I want to it support these encodings. 

Being able to work with mounted FTP servers in Windows 7. It works perfectly in ubuntu 11.04, but doesnt work with Windows 7.

You read all the mails, requests and forum-topics, you insert yourself in the community you have created, and you give us this fantastic Texteditor.

When the autocomplete popup is shown and the first item is highlighted, pressing UP key dismisses the popup and moves the cursor to the previous line. When the autocomplete popup is shown and the last item is highlighted, pressing DOWN key dismisses the popup and moves the cursor to the previous line.

I've been using a variety of text editors for decades, from vi to Notepad++ to TextMate to jEdit and beyond. Sublime surpasses them all, and has managed to exceed my expectations for a programmer's text editor.

For the poor saps like me who sometimes end up editing giant strings of SQL, it'd be nice to be able to enable bracket matching within strings. The way Vim does it is that brackets within strings can match other brackets within that same string, but never match brackets that are outside the string and vice-versa (i.e. brackets outside of a string never match brackets inside a string). That way, you get bracket matching within strings while avoiding the issue reported here:
http://sublimetext.userecho.com/topic/27094-context-aware-bracket-matching/

If Sublime is closed and I open a file, it shows up in the last open windows instead of a new one