I haven't found any editor that makes handling of split panes as streamlined as Emacs, and that's because while having the tabs tied to a single document is a sensible metaphor, it's just way faster to have two or three panes whose contents you can switch from an autocompleted list of buffers. No clicking around, no squinting your eyes at the little tab titles, no dragging and dropping the tabs to switch them from pane with awkward snapping in and out.
(buffers can be files, configurations panels, terminals, applications, whatever really)
But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.
Ah, excellent, just wanted to make sure there wasn't some magical insight i was missing out on by not being familiar with emacs.
re: clicking/squinting/dragging/animations those i would usually handle by things like keyboard shortcuts, configuring your global search to list tabs first, configuring animation.
I think what is more interesting is the idea to use the same buffers/windows for non-text-files. So, the first half is the idea of having all your tooling be text-based. There's some slider along, text driven by keyboard => gui driven by keyboard => gui driven by mouse. And then the second half of the idea seems to be how you separate text-editing/config/applications. So maybe along that slider, emacs mixes all sources / IDE groups sources within an application / separate applications for each source.
Maybe pushing everything to one edge of the slider is able to put one in a zen-like state. I guess for now I just try to find a sweet spot with my tools, where stuff i want to do fast i can do fast, and everything else is ok as is.
Every modern graphical editor I'm aware of lets you jump around in tabs/windows/panes etc. exclusively with hotkeys.
I don't know why people keeping talking about clicking around. They are all completely operable without resorting to clicking. Maybe not with IDEs, but with VS Code / Sublime / Atom, you don't need a mouse for anything I'm aware of.
(buffers can be files, configurations panels, terminals, applications, whatever really)
But editor ergonomics are always trumped by tool support, and Emacs' can be good, but it's never reliable in supporting environments that aren't Lisp and academic stuff like R and LaTeX.