This idea is not specific to Python, and would probably be useful if implemented generally based on indentation, but I'm going to describe it in terms of Python for clarity.

I often use "go to definition" to jump directly to a method. But it's sometimes hard get context because I can't see which class the method is inside of - I have to scroll up, sometimes really far, to see what the class is.

My idea is to reserve one line at the top of screen for each level of indentation of the current line. Then show the "parent" line as a "sticky header" at the top of the editor. The "sticky header" is often found in iOS, for example the contact list. Here's a video that illustrates the point. The class would always be visible on the first line, the method visible on the second. Maybe it could be useful to go further than this and make if statements and loops sticky, but I'm not sure about that.

Here's an example of the code review tool Phabricator doing this. Note the line number of the class is 185, but the first line shown is 201. The rest of the body has been collapsed so that the class line remains visible for context.


For a more extreme example, consider the following 5 line display. Obviously on such a small display the lines lost to headers reduce the amount of space you have to see the actual body, but a small example makes it easiest to see how this would work.

class LineZero(object):
    first_line = "bar"
    def second_line(self):
        third_line = "baz"
        fourth_line = 42

Right now if you scroll that, the class line disappears from view:

    first_line = "bar"
    def second_line(self):
        third_line = "baz"
        fourth_line = 42
        fifth_line = 5

I'm proposing that the class statement (as the root node in the tree of indentation) become "sticky", so instead the first line of the class scrolls out of view like this:

class LineZero(object):
    def second_line(self):
        third_line = "baz"
        fourth_line = 42
        fifth_line = 5

Then if you scrolled one line further, the method line would be sticky, and the first line of the method body scrolls out of view:

class LineZero(object):
    def second_line(self):
        fourth_line = 42
        fifth_line = 5
        sixth_line = None

Would that be possible?

Vim has a very nice feature called 'scrolloff' which allows to define a minimal number of lines to keep above and below the cursor when scrolling. It makes it very convenient to work with files where there's already content below the cursor ...

Like the ones in Opera browser.

I like using Ctrl + Scroll to change the font size (easy for presenting to other people) but the only thing missing is Ctrl + 0 to reset! 

A simple "Save a copy" function which save the current file under another name while keeping open the original.

Would be nice if the editor could save new files with a predefined charset.

My employer use ISO-8859-1 as default charset and I have to change this everytime I save a new file.

In Vim 7.3 they added a really nice feature allowing to display some syntax regions (selectors) as configurable unicode characters. It makes much easier to read some languages, like the following example for Javascript where "function" has been replaced by "𝑓", "this." by "@" and "return" by "↩" .

With the recent inclusion of code folding, which allows for "inline" folds, I think the editor is ready to implement this feature without much effort. 

I've tried to implement a plugin for this but I'm lacking one API function, which could work just like View.fold but allowing to set a custom character and syntax selector for its display, instead of the currently hardcoded fold icon.

Sublime Text (both 1 and 2) are packed with great functionality, and packages add much more. However, it often takes a web search to find out about some of Sublime's more obscure features.

Improve the discoverability of Sublime's manifold functionality. Some ideas:

* Optional tips-on-startup dialog (with "don't show next time" checkbox); especially useful for new users of the demo version

* Add a mechanism like `apropos` to search for commands/keybinds that may do what you want. Having a short plain-English description with each command would improve search discoverability. Descriptions would need to be associateable with both commands and specific keybinds. Add a help menu item labeled "I want to..." to open the apropos prompt.

* Add a mechanism for the user to get context-sensitive help for any keyboard command or menu item. Wire it up to a wiki to let the community help build up these docs.

* Add a help menu item "Keyboard shortcuts" which generates a human readable list of the current keybindings in a new buffer. This list could sort the binds by keystroke and include the short `apropos` description for each keybind.

* Require installed packages to provide apropos-style descriptions of all their commands and key bindings.

* Allow package creators to include a help file with their package. Make these help files accessible through a new help menu item "Package Help >".