Kakoune: Discussion: Portable support for vertical and horizontal splits

[cbuschardt]

Separating support for window management out to the window manager is great. That last thing the user needs is yet another tiling window manager with yet another set of keys. However there's some additional plumbing needed to support reliable vertical and horizontal splits.

Proposal:

• Introduce unified new-horizontal/new-vertical [requires supported terminal multiplexer or tiling wm]
• Add support for i3wm, bspwm, and others as appropriate
• new-horizontal should be bulletproof. [don't fallback to new on random wm's]

Use cases:

• left/right editable diffs
• temporary panes for search results
• debugging wrappers [locals/stack/command panes]

Clients like kakdiff could launch a customized tmux session with customized modifier keys [eg ctrl-w instead of ctrl-b] when no supported WM was available.

[lenormf]

There's tmux-new-horizontal and tmux-new-vertical to get a determistic behaviour. Moving between panes is done using the focus command.

[cbuschardt]

I'm aware of the tmux support. The issue is what happens when you're not running tmux. This is the portability issue :)

[occivink]

I don't know about i3, but I do know that bspwm lets you specify where the next window is going to be created, so it would definitely be possible for a wrapper script to offer that.

[cbuschardt]

That's idea, provide a wrapper script that works (TM). The question is what to do if there's no tiling window manager.

[lenormf]

The idea of not implementing i.e. window splitting in the editor itself was to only have a way to create windows from within kakoune easily, and let the window manager take care of the rest. Implementing additional commands that control where the windows will appear would break this premise, as it would allow the editor to control the window manager's behaviour.

It would open a can of worms as once it's possible to control the position of new windows, we will inevitably start wondering about ways to control layouts, workspaces etc. The idiomatic way in this case would be IMO for you to create an extra script that extends the default one with all the functionalities that you want in it, which you could share with everyone else afterwards.

There's no support for anything other than x11/tmux/iterm2/dvtm because nobody uses anything else yet, or probably because it's so easy to create such compatibility scripts to support your own window manager that nobody has bothered sharing theirs with upstream.

[cbuschardt]

There's no support for anything other than x11/tmux/iterm2/dvtm because nobody uses anything else yet, or probably because it's so easy to create such compatibility script

The issue is not users key bindings. Think bigger. There is already a thread requesting support for 'kakdiff' [vertical split diff].

How, precisely, would you write such a script for kakoune that would work unmodified on different systems?

[Delapouite]

There's no support for anything other than x11/tmux/iterm2/dvtm

I'm using kakoune with xmonad and it works great. Predictability of where horizontal or vertical windows are created is handled by the underlying layout.

[mawww]

It seems really overkill to implement window handling inside Kakoune, but I think we have a nice compromise for this problem:

We already have the new alias, which gets set by x11.kak or tmux.kak (or iterm2.kak), we could "standardise" new-vertical and new-horizontal so that scripts that want to ensure positioning can do it. If the underlying implementation (say x11.kak) cannot guarantee it, well its up to the user to switch to a window manager/terminal multiplexer that can provide that and write the support script for it. That means we would need more window manager specific scripts to handle this (or maybe there are some EWMH hints or something).

Frankly, it does not strike me as that urgent though, a kakdiff implementation could just rely on either the user or its WM to place the window in the right layout. Putting the windows side by side manually is a small inconvenience, but its still a one time operation.

[cbuschardt]

The compromise what I was hoping for.

A user could author a kakdiff or gdb script that launched tmux if no supported tiling WM was detected [and hide the bottom bar]. This combined with a standardized 'new-horizontal' and 'new-vertical' would produce a robust solution.

[cbuschardt]

This is a low priority request.

[lenormf]

There's no support for anything other than x11/tmux/iterm2/dvtm

I'm using kakoune with xmonad and it works great. Predictability of where horizontal or vertical windows are created is handled by the underlying layout.

xmonad is based on X11, so it's supported, I don't get the point.

[benjumanji]

I use bspwm. I'd like to start using kak seriously. Every plugin seems to assume there is only one true way of managing windows: tmux, and then a fallback to x11. This morning I am going to have a go at making a bspwm.kak that exports all the tmux names, either that or make bspwn names and then lobby every plugin developer to add my symbols. This seems not great. How should this be resolved?

[occivink]

This discussion has some insight on a potential direction that would allow you to create your own bspwm.kak (or fancynewwm.kak) and have plugins automatically support it. Plugins that already use the (new-ish) terminal alias should already allow this, but not all of them do.
Note that the terminal alias currently doesn't expose anything in the way of customizing (for example, deciding where the new window should appear), but we can agree on a common feature set that we want terminal creation to support and then add this.

[benjumanji]

Having read that thread I think the best path forward is for me right to Frankenstein my way through making things work nicely for _me_, and then perhaps report back here. To be clear: as I am on x11 I'm not actually blocked by anything, fzf et al all work just fine by spawning new terms. They just are placed horribly because bspwm's default automatic layout is not designed to handle "drawer" type preview and popup windows, so it will often split the editor right down the middle which is 100% dumber than it needs to be. my guess is we want split north / east / south / west (:bike: :house:)+ a split ratio all of which can be ignored if the underlying doesn't support it.

[mawww]

One possible direction for that would be to have all the terminal command implementation support an initial -vertical or -horizontal switch (only allowed as first argument, rest is forwarded), implementation are encouraged to honor those switches if possible. I wonder if this can be implemented easily in current terminal impls, or if supporting those extra switches is going to require ugly hacks.

I think this would be cleaner than the current split in many commands (like tmux-terminal-{vertical,horizontal,window}.

[andreyorst]

Setting size would be great option too. In fzf.kak I need to handle tmux slpits myself because I need to create splits of specific size depending on user configuration, and current tmux-terminal-{vertical,horizontal} as well as terminal alias doesn't support this. The way I see it could work, is that terminal command could accept these parameters:

• -side <(horizontal|vertical)>, but this could be split up to separate vertical or -horizontal
• -size <(rows/columns)[percentage]>, this will be context dependent. If split is horizontal - parameter is used as column number, if split is vertical, the size is used as row number. If VM/Multiplexer support script supports percentage, it will use it, otherwise it ignores it. If support script doesn't support amount as argument too, it ignores it and warns user that, say, X11 doesn't support size specifiers for new windows.

This also makes it not necessary to have different commands for each VM/Multiplexer, since terminal will handle all of those things based on environment.

[benjumanji]

I'd be happy with the above proposals. I'll try implementing them for my own bspwm plugin.

[benjumanji]

I guess i'm forgetting the lack of builtin support for defining commands with custom switches / options. I've found that a lack of getopt / shift operator to be quite annoying when trying to implement essentially "pop some args, forward the rest" style kakoune commands.

[andreyorst]

I guess i'm forgetting the lack of builtin support for defining commands with custom switches / options.

Yeah, I've did this in this manner for plug.kak

[FlyingWombat]

It hasn't been mentioned, so I'll pipe up:
Please don't forget about wayland compositors like Sway!

[andreyorst]

I'm not sure if this will cause any problem. X11 currently handled in a way that an app is called from the shell, so it will work in sway too. As for splits, sway just needs a support script and a detection mechanism.

[lenormf]

Could this be closed?

[alexherbo2]

For reference, I created [terminal-mode.kak] to address this issue.

[FlyingWombat]

Could this be closed?

Has it been addressed yet? There have been some ideas thrown around, but as far as I know, nothing has really been done about it (I also haven't been paying close attention). terminal-mode.kak (haven't used it yet) looks like it could be a decent option for defining a user-interface for window operations, but I think that is aside from the heart of this issue.

TL;DR
Kakoune, even though it doesn't implement windowing, should be WM-aware by defining windowing interfaces.

Compared to other editors, Kakoune's windowing capabilities are lacking. Kakoune, by design, doesn't do windowing itself. ( I agree that's the WM's job), but that doesn't mean it can't be window-manager aware, and still provide a good windowing experience to the user.

As others have suggested in this thread. I think a standard interface for windowing needs to be defined, for splits, tabs/collections, resizing, etc. The way things are now, plugins that want a smooth windowing experience (such as fzf.kak) each implement windowing operations themselves. The result being, that they work well for the one WM (tmux) the author uses, and not for anything else. With a common interface, the experience will be more or less the same on any WM.

By default, the functions of those interfaces will just be stubs, and will require a plugin to implement support for a specific window manager (tmux, i3, etc.). This way, Plugins will just say "I want a 70% vertical split", and Kakoune will (ideally) detect the WM it is running in, and call the corresponding function in the appropriate WM plugin.

The core project just has to define the interfaces, and maybe WM detection. The implementations for each WM can be left to 3rd-party plugins (or included, if we want).

If this has already been done, please let me know, so I can enjoy using it.

[Screwtapello]

The thing is, "a 70% vertical split" is an idea that only means anything with a certain model of how windows are created and arranged. That model happens to be implemented by tmux and i3, but it's not widely implemented outside of those two - you could approximate it (by effectively writing your own window-tiling add-on) for traditional floating-window managers (metacity, WindowMaker, etc.) but for window managers that implement other models (dwm, awesome, etc.) it's just not possible.

I think the best solution is basically what we have now - a very limited set of standard aliases that are reliably available, with WM-specific commands that you can use if you're happy for your plugin to be non-portable. That way the plugin author knows when they're doing something non-portable, and they can advertise that requirement in their README.

Also, if there's a bunch of standard APIs that don't work properly (or at all) for X11, that effectively makes X11 a deprecated and not-fully-supported platform. It's pretty reasonable for a plugin author to say "I don't care about supporting this platform", but it's a much bigger thing for Kakoune as a whole to demote one of the most popular platforms to second-tier or below.

[FlyingWombat]

If "we want 100% manual window management" is the consensus, then what we have now is a good solution.

You are right, portability to floating window managers (that don't already have a tiling extension, like GNOME and KDE do) will be difficult. Correct me if I'm wrong, but I feel like anyone who uses a floating window manager would prefer to just use tmux anyway, so that everything can be in one desktop window.
The thing is, the standard paradigm that every major editor has settled on is tiling window management -- just, most implement that themselves within the application for the sake of portability, and because floating window managers don't really do that. We are free to come up with an alternative paradigm, but we haven't.

I like Kakoune, and I like that at its base it is small, simple, and understandable. But, it has trouble expanding properly into a full development environment. I think the biggest roadblock to this is the lack of a standard window management API; that prevents 3rd party plugins from coordinating to provide more advanced features.

That way the plugin author knows when they're doing something non-portable

This is important to have. And it is why we should be conservative in what we define for the standard WM API. Keep it limited to operations that could reasonably be implemented for the majority of environments Kakoune will be running in.
I think that most users on floating WMs will be happy to use tmux, kitty, iterm, etc. as their window management system for Kakoune, when they want to use window management features. So I think that supporting floating WMs directly is a rather niche environment.

... that effectively makes X11 a deprecated and not-fully-supported platform

Isn't that already the case for tmux vs X11? AFAIK the only API Kakoune has for X11 is new-terminal.
"X11 support" itself is a little nonsensical because (AFAIK) X11 doesn't define any window-management APIs itself, but rather leaves that to the various WMs. For what standard WM APIs X11 does have, supporting those shouldn't be a problem, and those functions will cascade naturally to a plugin for defining support for a specific WM.

[andreyorst]

The thing is, "a 70% vertical split" is an idea that only means anything with a certain model of how windows are created and arranged. That model happens to be implemented by tmux and i3, but it's not widely implemented outside of those two

As I've suggested earlier - https://github.com/mawww/kakoune/issues/1363#issuecomment-473628462 - WMs that don't support this should just ignore these parameters:

:terminal -type horizontal -size 30% 

would create a horizontal split in tmux, i3, or kitty, but will fallback to basic terminal in GNOME, because GNOME doesn't support these capabilities.

Right now Kakoune already supports several window managers. Why not make this more universal by providing single terminal command that has well formed set of switches and can actually inform its user whether this WM supports -size and -type switches or not in the *debug* buffer or via message, or even in the info box.

[lenormf]

If the command (i.e. WM/multiplexer) that backs :terminal doesn't support the flags or the specific window placement/size passed as argument, then a window will be spawned randomly, and the command fails to fulfil the contract established by its API.

If the editor allows -type horizontal (and others), then it must honour that request, otherwise it's a bug.

Since there's no reliable way of instructing an arbitrary multiplexer/WM where or how to place a new window, the core spawns "a window", and it's up to the user to customise that behaviour. Third-party plugins seem more suited to this task, to avoid the unpredictability of arbitrary flags that may or may not be interpreted by :terminal.

[andreyorst]

If the editor allows -type horizontal (and others), then it must honour that request, otherwise it's a bug.

Not if this is a documented behavior.