This is another proof of how editors and terminal multiplexers should really be just one thing.

Editors are replicating terminal multiplexer functionalities - tabs, windows, and now with terminal emulation they have become terminal multiplexers. Terminal multiplexers are also replicating editor features (copy-mode of tmux, for example). Unfortunatly neither has reached a state to completely supersede the other - I always find vim's window-manipulating commands obscure, and copy-pasting with tmux is never as satisfactory as in vim. I suspect that such a state will never be reached, since both party are still keeping their narrow mindsets - vim still tries to remain an editor, and tmux still tries to remain a terminal multiplexer.

The world can benefit from something that is built as both an editor and a terminal multiplexer from the very beginning. There is acme (http://en.wikipedia.org/wiki/Acme_%28text_editor%29), but we need something slightly more elaborate and friendlier to the keyboard.

(There is also emacs, which is both an editor and a terminal multiplexer. But it is also a news reader, a web browser, and a million other things. Something that is "just" both an editor and a terminal multiplexer is probably better for the reset of us.)

No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead detect that it runs within a terminal multiplexer and instruct it to create a new window. When I find the time I will try to experiment with this design in vis.

https://github.com/martanne/vis

As for the copy mode, in my opinion the multiplexer should use the editor as a filter (which requires that the editor uses stderr for its regular output). The whole scroll back buffer is piped to the editor and whatever the editor writes to stdout is kept around in a copy buffer.

That is the way it is implemented in the latest dvtm releases.

http://www.brain-dump.org/projects/dvtm/