Feature request: support for goto_split:<n> where <n> is a split index

[alecthomas]

This would be lovely to have, and is supported by at least Kitty and iTerm:

• Kitty first-window - cmd+<n>
• iTerm (no docs) - cmd+<n>

[qwerasd205]

If these were implemented we'd also want to add index indicators to the splits somehow because otherwise it wouldn't really be clear what the index of a given split is. That aside, this is a sound idea.

[alecthomas]

That would be great, though the indexes are deterministic in other terminals (and presumably in Kitty), so in practice it's not really a big issue.

[edrozenberg]

Took a quick shot at an indexnum mockup. Pretty clear the index would need to be top right of each split:

• Top left would block part of a shell prompt potentially*
• Bottom left/right would block part of editor command lines, tui info lines/key legends (for ex. mc) etc.
  (* but international/RTL considerations might make top left desirable in some cases?)

The other option would be to make split dividers thick enough to house the index number along the split line itself (interrupt the split line), but these thick dividers would waste space and look bad.

With indexnums blocking part of the content, it would be great for them to be optional and able to be shown/hidden with a shortcut/menu item (maybe per tab / per window). With a small number of splits (1-4) it's not too hard for the user to memorize the indexnums and not need the indexnum display to always be enabled.

On the design - if the color background for each indexnum is too close to a light-colored split line, it creates the visual illusion that the split line is missing a piece in that location. Either the color background should be far enough from the split line for that not to be the case, or it could be flush/integrated with the split line.

[jcollie]

Yes, I would say that the indexes should definitely be transient, triggered by a keybind action of some sort (similar to the way the resize overlay is handled). The positioning should be user configurable, although top-left is fine as a default. The color of the overlay should be left up to the apprt. Theming the indexes I would prefer to see handled later in a different PR, or left up to the user through custom CSS on GTK (although no such similar mechanism exists on macOS).

Also, the numbering may be deterministic, it may not be obvious to users what that order is. Better to have a way to show the numbers to the user.

[rhodes-b]

Also, the numbering may be deterministic, it may not be obvious to users what that order is. Better to have a way to show the numbers to the user.

ditto this, I think not showing the numbers all the time could be a good idea / having a keybind that shows a overlay (either fades out or toggle) to show the split numbers would be a good addition onto this feature (most likely as a separate issue)

I think an alternative idea could be a goto_split keybind that by default is trigger sequence which toggles the decorations to show the numbers (it shows until you select one)

[edrozenberg]

an alternative idea could be a goto_split keybind

Great idea, better imo than permanently covering any content with numbers. A keybind to show an indexnum map/legend overlay temporarily (for ex. Ctrl + Alt + S, user-defined followed by a number matching the split index), and also keybinds for direct split access without needing to view the overlay (for ex. Ctrl + Alt + 1/2/3 etc, user-defined). Maybe something like this (transparency/blur) -

Maybe offer both options? Optional indexnums in the corners, and also ability to view overlay (🚰 ).

Open Q: what about > 9 splits? Support this? It's not obvious how to address double-digit split indexnums with shortcuts. Would require something like the popup picker menus in Helix (hx) ? Assign indexnums only to the first 9 splits and anything > 9 is not directly addressable?