It would be very handy if there was a simple boolean option that would cause the editor to resize itself when the sidebar is toggled.

For instance, say that the editor window does not have the sidebar visible and it's currently 800px wide. Let's also assume that the sidebar was previously set to 200px.

When the new feature that I'm proposing is enabled and the sidebar hotkey is pressed, the editor window would get the width of the sidebar and resize itself to be that much wider on the side where the sidebar appears. So the total window width would be 1000px. When the sidebar is closed, the window would decrease back down to 800px.

This behavior is roughly similar to how the old Textmate 1.x file drawer functioned - the drawer could open without affecting the placement of the rest of the window. This would be very very handy for people that don't use their editor in fullscreen mode.

Here is a simple test-case you can try in ST’s console:

view.run_command("insert_snippet", {"contents" : "snippet: ${1/.+/1/}$1${1/.+/2/} ${1/.+/1/}$1${1/.+/2/} ${1/.+/1/}$1${1/.+/2/}"})

When you have a snippet with more than one mirrored replacements going before the mirrored tabstops, the order of the inserted snippets is broken.

So, in example above you can see that all three space-separated parts are equal, however if you’d run this snippet and write something like `foo`, then you’d get

snippet: 1foo2 foo12 foo12

and that’s wrong, it should be:

snippet: 1foo2 1foo2 1foo2

That bug is really a stopper for what I want to do :(

In ST2 is more default shortcuts that helpfull working with this tool. But Sometimes there i'm installed many great plugins that are encountered shortcut conflicts with default keymap shortcuts.  This problem was posted in ST2 forum: http://www.sublimetext.com/forum/viewtopic.php?f=4&t=5569&p=32246&hilit=keymap#p32246. So, maybe keymap manager is good resolution but I thing that better is situation when ST2 encounter shortcut conflicts (there is in Visual Studio or Jetbrains IDE tools as RubyMine) . So, another resolution is added bool option when an user would be decided that any plugin can't encounter default shortcut (users keymaping wolud be ignored).

Pawel

Right now you can change the `word_separators`, for example exclude the hyphen symbol (`-`) from it, and if you do this, moving inside a “words” while holding `ctrl` would skip the hyphen.

The expected behavior is to count it (like in TextMate), so in a word “someWord-with_something” the ctrl-stops would be “some|Word|-with|_something”, but right now it's “some|Word-with|_something”.

Motivation

As a software developer, I am mostly viewing source code files in Sublime Text, which have comparatively short lines, as opposed to continuous texts with long lines and a lot of virtual line breaks.

Therefore, most of the text that I view and edit is on the left side of the screen. Because of that, my head is also mostly turned a bit to the left when editing source code. As a "workaround", I can position the Sublime Text window on the screen, such that the left half of the text is positioned centrally on the screen.

Consequently, space on the right side of the text panel is mostly unused, and not much looked at, unless for very long lines of code.

Inspiration: Books and Magazines

Books and magazines have a two-page layout, while still representing one long text. The text of a book can be thought a a long, continuous text, when all the pages are cut out and glued together from top to bottom. This representation of the book would be equal to the logical representation of scrollable text in Sublime Text.

This principle can also be applied in reverse.

Proposal

I propose an option that turns a tab (or all of them) into a "book layout" or "magazine layout" view. This means that the view will be split horizontally, but the two split views will be connected in this way:

- Both split views represent the same document, in the same state.

- Both split views always have the same width and height. If the window size changes, the width of the window must be divided equally between both split views.

- If one of the two split views is scrolled up or down, the other will automatically be scrolled by the same amount.

- The first line on the right split view is always the text line that comes after the last line on the left split view.

- Scrolling is possible beyond the end of the document; when scrolling all the way down, the right scrollbar is empty (out of document), and the last line on the right scroll view is the last line of the document.

- For both split views, there is only one scrollbar, preferably in the middle between the split views.

- The text cursor can only be in one of the two split views (of course).

- When the cursor is on the last line of the left split view and moves down, it will arrive on the first line of the right split view, and vice versa.

- Scrolling up or down by one page scrolls by the height of just *one* of the split views, not both.

- When this layout is active, the view cannot be split further.

Benefits

Should be rather obvious. The user has an intuitive layout that is already known from print publications. Keeping an overview over larger parts of the document is easier. More of the window area is used for useful purposes.

Things to consider

When resizing the window, I am not sure how the split views should react to that. Which of the two has the "canonical" position? - I would propose the left, just out of intuition.

Cursor jumping from bottom left to top right might be irritating at first. Maybe a visual clue that shows the cursor actually "jumping" over, or illustrates the shift of focus of the active line, would be helpful.

Notes

As far as I know, no text editor has this feature. That's a pity to me, because I find this idea quite straightforward and useful. Emacs can be configured to work this way, with a bit of programming, but honestly, who wants to do that? - If you know of any editors supporting such a feature, please let me know!

Also, if anyone likes this idea and feels that he can make a good design mockup, I would be thankful for that.

Such a feature could also be implemented in other text editors, or IDEs, or even web/document browsers. If anyone intends to start a similar request or implementation on any other application, please let me know.

 When clicking the button in the bottom right corner to select another language (syntax highlighting, that is), I'm greeted by a screen high menu.

It would be very convenient to have a "favourite languages" feature, which effectively groups all the non-favourites into a separate "other languages" submenu, thus saving me scrolling around and looking for that one of maybe 5 languages I could possibly need.