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.

Create a panel or window that shows and maps the colors used in the current file, especially CSS files. Attached is a screen grab from TopStyle 4.

When both keys and values are symbols, the colors all run together. A simple fix would be to not consume the colon in the regular expression. I was able to accomplish this by changing "(:)(?!:)" to "(?=:)(?!::)", as in:

    <dict>

      <key>captures</key>

      <dict>

        <key>1</key>

        <dict>

          <key>name</key>

          <string>punctuation.definition.constant.ruby</string>

        </dict>

      </dict>

      <key>comment</key>

      <string>symbols</string>

      <key>match</key>

      <string>(?&gt;[a-zA-Z_]\w*(?&gt;[?!])?)(?=:)(?!::)</string>

      <key>name</key>

      <string>constant.other.symbol.ruby.19syntax</string>

    </dict>

This type of accent does not work for me: á ó ń (letter and accent are two separate symbols).

However, there's a topic called Tab titles do not support accented letters and it seems it should work in the document itself.

One of the best editor UI features of Brief (I'll not say more, those who know, know), was how the Home and End key were handled. 

• On first press they went to the end or start of the current line.
• On 2nd press they went to the bottom or top of the current viewport (what you can see on the screen)
• On the 3rd press they went to the end or start of the file.

The ease of using this interface can not be glorified enough.  It is amazing.  Considering your editor's clear aim is to be glorious in every way, I highly recommend you implement this unappreciated (but unequaled) feature.

PS

You could even generalize it to allow function binding to n-tery presses of a given control key in the plugins.  But that matters less to me than this specific functionality. 

Enable remote pairing without desktop screen sharing (something like vim and tmux: http://pivotallabs.com/how-we-use-tmux-for-remote-pair-programming/ )