[mehalter]

📑 Description

AstroNvim v7 is going to be moving to smart-splits v3 which separates out the various supported backends. With this we are going to be making them optional to the user so they can opt into whichever backends they want on their system. This does a first pass at adding these in with the proper logic to handle however the user may end up having them setup. We can leave this as a draft until the v7 release is made

This basically takes the pattern of:

• if the backend is a terminal emulator, add it to the end of the priority
• if the backend is a terminal multiplexer, add it to the beginning of the priority

Naturally people won't be using more than one terminal emulator at one time, practically people shouldn't be in nested terminal multiplexers so I think this out of the box behavior of how the priority list would be built if they added all of them should be solid.

Depends on:

• AstroNvim v7 AstroNvim#2907

📖 Additional Information

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[mrjones2014]

practically people shouldn't be in nested terminal multiplexers

I have actually gotten issues filed to smart-splits.nvim about people, for example, using Kitty's mux by default but sometimes also dropping into a tmux session lol

I think this still handles that case though.

[mrjones2014]

LGTM thanks for tackling this!

[mrjones2014]

I'm not super familiar with the conventions of this repo yet so idk where exactly it would go but it might be worth extracting this to a shared helper function somewhere

[mehalter]

yeah we do have a small "utility" file for AstroCommunity but it has focused on some pretty general things that is useful for any and all plugin specs. Not sure if we want to expand it to being for more specific stuff. Not sure what the best pattern is here honestly

[mrjones2014]

Maybe something like lua/astrocommunity/split-and-window/utils.lua or something? it's a little tricky since smart-splits.nvim itself is in core, so we don't have a natural place here like lua/astrocommunity/split-and-window/smart-splits/utils.lua which is what I would otherwise recommend.

[mehalter]

practically people shouldn't be in nested terminal multiplexers

I have actually gotten issues filed to smart-splits.nvim about people, for example, using Kitty's mux by default but sometimes also dropping into a tmux session lol

I think this still handles that case though.

Oh yeah, this is the main case I'm thinking about. I am not really considering kitty as a true "terminal multiplexer" it just has similar features like ghostty. I would expect people in a terminal session to really use at maximum 1 terminal multiplexer application (zellij/tmux) and 1 terminal emulator (ghostty/kitty) and we should prefer the true multiplexers over the terminal emulator

[mrjones2014]

FYI there’s been a community backend for Herdr that popped up if you wanna include that one

https://github.com/smart-splits-nvim/smart-splits.nvim#community-backends

[mrjones2014]

Oh lmao you beat me to it