Implement Kakoune-style client-server model for sharing buffers across windows in different terminals

[malte-v]

One thing I really like about Kakoune is that it lets me use my X11 window manager for window management (duh) while still sharing buffers across windows. Kakoune achieves this using a sort of client-server model where one Kakoune process can attach to another one running in a different terminal, so effectively multiple terminals are controlled by a single editor instance. You could alternatively use tmux if you want the "vim experience", but I really enjoy not having to think about two layers of window management (editor windows/desktop windows). One other nice consequence is that you can arbitrarily mix windows containing editor buffers and windows belonging to other (graphical) applications.

What are your thoughts?

[malte-v]

I guess you could also keep the built-in window splitting features if people want to have that. It would just make things more complicated since one would have to distinguish between windows from different terminals and window splits.

[pickfire]

I think kakoune approach is nice for people who can do many terminals (like the time when I was using a tiling vm). Otherwise it doesn't help much. I still think it would be nice to have it, not sure how to implement it though. Wonder if @archseer have any thoughts on this.

[cessen]

I'm against removing the built-in splitting features, as I expect that to be my primary workflow. I don't really view it as two layers of window management. (And come to think of it, I'm now remembering that this is one of the reasons I didn't dive more into kakoune, despite it otherwise seeming really cool.)

As for client/server capabilities, I'm pretty indifferent. I certainly wouldn't try to stand in the way of such a feature, but don't consider it important myself.

[CBenoit]

I don't really use the splitting feature because i3 does the job for me, but I think it can be useful to some people. However, I really like the client/server architecture of kakoune allowing me to open multiple windows when working on the same instance (very useful when working using multiple screens). That's not the only approach though: in (doom) emacs I used multiple windows but I'm not sure it was client/server architecture.

[vv9k]

I'm against removing the built-in splitting features, as I expect that to be my primary workflow. I don't really view it as two layers of window management.

Same for me, I use both tmux and neovim splits + tabs together and it works perfectly. I use tmux to launch a terminal next to the editor or tail logs while I use neovim splits and tabs to open separate documents.

EDIT:
The flip side of the coin is that I have to memorize two sets of keybindings to navigate through the splits but In the end the distinction between terminal and editor splits is worth it at least for my use case.

[CBenoit]

So consensus so far appears to be in favor of keeping the built-in splits.
However, I'm strongly in favor of the ability to share buffers across windows.

[simias]

For me an additional advantage of being able to spawn several windows for the same editing session is to be able to use multiple monitors easily. Back when I used Emacs it was my main use for frames, for instance in order to have a compilation buffer on my secondary monitor and not clutter my main editing window.

Vim is really, really bad at this window management stuff IMO, so it's really not an example worth following (it still baffles me how anybody thought that Vim tabs were a good idea in their current implementation for instance).

[archseer]

I would like to see some sort of a client/server session one day in the future. The editing model is built on operational transforms, so I've been wanting to experiment with a collab mode for pair programming: one server instance and two user clients connected via ssh.

All this is of course a whole lot of work.

[pickfire]

two user clients

I wish the two clients can have different configurations but that is even harder.

[CBenoit]

two user clients

I wish the two clients can have different configurations but that is even harder.

Actually it would probably be the default behavior. We would work with transactions, not configurations.

I would like to see some sort of a client/server session one day in the future. The editing model is built on operational transforms, so I've been wanting to experiment with a collab mode for pair programming: one server instance and two user clients connected via ssh.

All this is of course a whole lot of work.

Not for tomorrow but very happy to hear that.
I was very excited when I saw CoreMirror 6 collab API.

[kirawi]

Are transactions like CRDTs, or OTs?

[Cons-Cat]

I like that Kakoune works very well with the Kitty terminal because of this. Kakoune itself can create a new Kitty split, then launch some process (like Ranger or Broot or a Git porcelain) inside that new window automatically, using the same mechanism as making another window for code. It makes the workflow feel very cohesive imo.

I don't mind having Emacs manage splits because Emacs has some Lisp package equivalent to every terminal app I'd ever use, but it seems really impossible imho for anything other than Emacs to achieve that.