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.