I won't even give it a chance over ST until I can resize panes, unfortunately. How that isn't a feature is beyond me.

there is a package for that: https://github.com/santip/resize-panes

apm install resize-panes

But how can putting this functionality into an extension package be considered a reasonable design choice? It isn't an editing "component" like e.g. Scintilla, it's meant to be a general purpose editor: offering a decent out-of-the-box user experience and providing a sensible foundation for extensions should be two of the top priorities.

> But how can putting this functionality into an extension package be considered a reasonable design choice?

Obviously you don't use emacs.

Because you can then separate out what re-sizing is. Maybe you write a plugin that lets you drag with a mouse to re-size, but maybe someone else never uses their mouse, and would prefer a re-size plugin which auto re-sizes everything according to a tiling layout similar to a tiling window manager.

Separating it out has a lot of advantages, especially by not putting in much opinion by default.

> But how can putting this functionality into an extension package be considered a reasonable design choice?

I like the design of Atom, because it allows me to freely compose an editor that does exactly what I want, and nothing more. While multiple panes is a requirement for bpicolo (and you?), I use multiple panes in Atom (my primary editor) and haven't felt the need to resize them. Am I the minority, or are the others? Or is it 50/50? Basically, we don't know until the editor has time to grow, and its community has a chance to dictate what features are required.

That should be pretty easy. As I recall right, Sublime is a really basic core (we're talking notepad.exe levels), and various core plugins actually make up the main functionality of the application.