[Feature]: Smart split creation

[IndianBoy42]

Similar Issues

• [X] Before filing, I have searched for similar issues.

Description

I don't know if you consider this part of the scope of this plugin but a feature that seems to fit under the banner of smart-splits is smart split creation.

Some ideas I have are:

• move_cursor_or_split - move the cursor in a direction or create a split in that direction if there is no window in that direction
• split_longest_side - create a split dividing the current window along the longest side. so if its a very wide window we get a vertical split and if its a tall window then we get a horizontal split. (potentially with some cmd that is immediately run in that window)

[mrjones2014]

Hm, it sounds interesting but there are some semantics we'd have to nail down.

move_cursor_or_split, how does this work with config.wrap_at_edge = true?

split_longest_side should be relatively easy, basically:

local win = vim.api.nvim_get_current_win()
if vim.api.nvim_win_get_height(win) > vim.api.nvim_win_get_height(win) then
  vim.cmd('sp')
else
  vim.cmd('vsp')
end

Could you expand on how you see the semantics of move_cursor_or_split working, especially with relation to config.wrap_at_edge = true?

Consider also that there may be a mux window past the edge of the current Neovim split that we can move to. What happens if you move_cursor_or_split from a pane that is at the edge of Neovim, but there is a mux window next to it? Do we move to the mux window, or do we split?

[IndianBoy42]

wrap_at_edge I think should just not be respected by move_or_split. Maybe have change wrap_at_edge to at_edge="wrap" and have at_edge="split"? That is probably more consistent considering you don't have move_or_wrap. As long as at_edge can be chosen at keybinding time so the user can have all of the behaviors to different keys if they want

The semantics are basically move if possible and if there isn't a place to move, make a split. A mux window counts as a place to move so it should probably move. Wait how do mux windows interact with the wrap_at_edge config? It just goes to the mux window right?

True, split_longest_side does seem simple, any reason not to include it anyway to help users? It could get a bit more complicated to handle running a command after like :SplitLongest edit some_file

[mrjones2014]

Wait how do mux windows interact with the wrap_at_edge config? It just goes to the mux window right?

Yeah, basically, when you're at a Neovim edge, the exact implementation varies per mux backend (tmux vs. Wezterm vs. Kitty) but it checks in some way if there is a mux window we can move to, and if not, then it wraps to the other side of Neovim.

Maybe have change wrap_at_edge to at_edge="wrap" and have at_edge="split"?

I try to avoid breaking changes if at all possible, but I suppose that's possible. I made a similar change when adding other mux backends, had config auto migrate itself, and printed a deprecation notice, which we could also do for this (wrap_at_edge = true would migrate to at_edge = 'wrap'). We'd need to include at_edge="stop" or something as well, in case you want neither of those behaviors.

[IndianBoy42]

Yeah, split, wrap and stop sounds correct.