Emacs has a nice package called expand-region[1] which works in a similar, although more context-sensitive fashion. There's a nice intro screencast by Emacs Rocks[2] as well.

The context-sensitivity is handled by having a list of expansion/contraction functions to try in sequence, so your region grows outwards by different units. Or you can specify a specific expansion function (like, er/mark-outside-python-string) upfront.

As an example, the expand function list I have for a python buffer open is:

    (er/mark-word
    er/mark-symbol
    er/mark-symbol-with-prefix
    er/mark-next-accessor
    er/mark-method-call
    er/mark-inside-pairs
    er/mark-outside-pairs
    er/mark-comment
    er/mark-inside-python-string
    er/mark-outside-python-string
    er/mark-python-statement
    er/mark-python-block
    er/mark-python-block-and-decorator
    er/mark-outer-python-block)

[1] https://github.com/magnars/expand-region.el or from ELPA

[2] http://emacsrocks.com/e09.html

Very cool.

Indeed, although that one is useless if you want to do something like wrap the current statement in an "if" or "while" or similar. "Expand Selection to Brackets" will actually include the lines containing the brackets, so you can't use it to select the contents of a block.

Sublime also has "Expand Selection to Scope", except it doesn't really work that well: First invocation it chooses the current symbol, on 2nd the current brace block except the braces, on 3rd the braces themselves, and so on.

And it also has "Expand Selection to Indentation", but I don't see use for it in cases where you want to manipulate blocks of code, since it nearly always doesn't select what you want.

What I'd like is a command, let's call it "Expand Selection to Statement or Block", that:

* On 1st invocation, selects the current line.

    int foo(int bar) {
        bar = mogrify(bar);

        if (bar > 0) {
            slartibartfast = 42;

            [[baz = bar + 1;]]    # <-- [[ selection ]]
            print_report();
        }
        return bar;
    }

* On 2nd invocation, expands to the current contiguous set of lines, bounded by either empty lines or language-specific block (usually braces, or in Ruby's case, "if/while/..." until "end"), but not including the boundary:

    int foo(int bar) {
        bar = mogrify(bar);

        if (bar > 0) {
            slartibartfast = 42;

            [[baz = bar + 1;
            print_report();]]
        }
        return bar;
    }

* On 3rd invocation, expands to the current contents of the block, excluding braces and excluding the lines containing the braces.

    int foo(int bar) {
        bar = mogrify(bar);

        if (bar > 0) {
            [[slartibartfast = 42;

            baz = bar + 1;
            print_report();]]
        }
        return bar;
    }

* On 4rd invocation, expands to the enveloping statement that uses the block:

    int foo(int bar) {
        bar = mogrify(bar);

        [[if (bar > 0) {
            slartibartfast = 42;

            baz = bar + 1;
            print_report();
        }]]
        return bar;
    }

* On 5th invocation, it would continue to step 2, ie., looking for more lines that are contiguous with the current selection:

    int foo(int bar) {
        bar = mogrify(bar);

        [[if (bar > 0) {
            slartibartfast = 42;

            baz = bar + 1;
            print_report();
        }
        return bar;]]
    }

* And so on. Eventually it will get to the entire function declaration.

Combined with a "wrap selection in braces"-type command (that indented the selection, wrapped it in braces, and placed the caret at the beginning so you could start typing something like "if (...) {") you would have a fairly powerful block-manipulating shortcut.

It would probably be quite trivial to write such a plugin. I might try my hand at this. Not sure how much language sensitivity it would need, might be doable without anything at all.

Good explanation. Thanks.

Talking of contiguous lines. I like macros of the following form for quickly hopping around vertically in a file:

    // .sublime-macro

    [
        {"command": "move", "args": {"by": "stops", "empty_line": true, "forward": false}}
    ]

    // .sublime-macro

    [
        {"command": "move", "args": {"by": "stops", "empty_line": true, "forward": false, "extend": true}}
    ]

    // .sublime-keymap

    { "keys": ["ctrl+up"], "command": "run_macro_file", "args": {"file": "Packages/User/HopUp.sublime-macro"} }
    { "keys": ["ctrl+shift+up"], "command": "run_macro_file", "args": {"file": "Packages/User/HopUpSelect.sublime-macro"} },

Very nice, I'm copying that one! You don't actually have to use macros for that. This will suffice (in your .sublime-keymap):

    {"keys": ["alt+up"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": false}},
    {"keys": ["alt+down"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": true}},
    {"keys": ["shift+alt+up"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": false, "extend": true}},
    {"keys": ["shift+alt+down"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": true, "extend": true}},

(Changed it to alt instead of ctrl because that's how I like it.)

Oops. Right enough. It was in its own file because before I knew about stops+empty_line, the macro was simply a compound equivalent to pressing up 4 times.

IntelliJ IDEA has both "expand selection outward" and "wrap selection in if/trycatch/while/etc" functions. They both work pretty much how you describe them here. They're language-dependent, too, so they work in any language that the IDE can understand internally.

Thanks for the tip. I am not interested in switching from Sublime to something like IDEA, though.

(IDEA is a Java/Swing app, and I'm very sensitive to apps that don't look or feel native on OS X. Yes, Sublime is crude in places, but at least looks and feels native. Being a Swing app it promotes certain GUI conventions that have not been relevant since the early 2000s. It's tabs and toolbar hell and looks like something out of a bad Windows nightmare. Sorry if that sounds snobby, but if I didn't like beautiful GUIs I would not be using a Mac.)

So you sacrifice usability for how pretty you find the IDE's gui?

I don't know what others do, but I actually hide the toolbars in my IDEs (I use several JetBrains products: PyCharm and IntelliJ mostly, PHPStorm and RubyMine to a lesser extent.) PyCharm actually received a facelift recently that I hope finds its way to the other products as well.

All JetBrians products ship with several skins (ctrl+tilde brings up the menu) and I've never found any trouble getting them the way I want. I do find XCode (which is my go-to editor for C and C++ not being an ObjectiveC developer myself) to be a very good looking IDE but personally, I'd never sacrifice function. It's just too important. IMHO, of course.

No, I do not.

Xcode is also native (although not very pretty), but it is a horrible IDE. I use Sublime for my ObjC coding, although I am forced to use Xcode for some things that ST cannot do, like adding files to a project, editing compilation flags or working with .xib and Core Data .momd files.

It's a compromise. IDEA is too ugly to use, Sublime lacks some features but is great in most areas.

Not to debate you, because hey, it's your perogative. But I want to just ask this though and give you the last word with it:

Given that many of the features you're talking about actually do exist in IntelliJ, etc, doesn't that mean that yes, you are sacrificing function for form?

Yes, it's a compromise. It's not all about function, or all about form. If ST is 90% beautiful, and IDEA is 0% beautiful, then I will choose Sublime even if it's 5% less functional.

There are other factors at play such as speed; Sublime is lightning fast, IDEA is not. And afaik, IDEA does not support Sublime-style multiple carets.

It really depends on what you're doing. For me (Java), IDEA is about 50% beautiful but 500% functional, and that's what leaves me with it.

Vim does a very good job of this:

    vi{
    v%