XIxiaq·Mar 3, 2015
I think the goal we are trying to achieve are the same. Having the editor and the terminal multiplexer communicating with each other is basically a modular approach to the "editor and terminal multiplexer in one" idea, which allows you to combine the editor and the terminal multiplexer freely. However, such integration requires the editor to have specific knowledge of the terminal multiplexer, e.g. the editor needs to know that tmux uses the split-window command to split a window, and the -h and -v options (or similar knowledge on dvtm); any knowledge mismatch can lead to subtle interop bugs. Also, the editor might gradually evolve to require specific versions of the terminal multiplexer and that will make installation a bit more cumbersome. These are signs of very tight coupling.
So the idea is, if you are going to have unavoidable tight
Read the rest
coupling, you might better build them as one piece of software from the beginning. That eliminates all interop issues automatically and since you designed the UI of the editor and terminal multiplexer as a whole, the user experience can be much more smooth.
Though I am pessimistic about the modular approach, I would still be very happy to see it implemented. I will admit your success if it turns out to be good enough :)
PS. I have looked at your vis before and having modern, alternative vi-like editors is always exciting! Though not quite related, I would like to invite to take a look at my modern, alternative shell: https://github.com/elves/elvish