[FEATURE] Remodel navigation logic

[Necrom4]

This PR aims to establish a more natural navigation logic, with the usual Neovim keymaps, tab completion and others.

This will close #35

• The previous version allowed to perform all key actions at any time, but they weren't the most "natural".
• This version introduces a "Selection Mode", where the user's cursor is replaced by an highlighting of a header element, and they can naviate the header using the left/right arrow keys or h/l. Up/Down arrow keys or jk scroll the detailed Result view. Tab/Shift+Tab scrolls the multi-results view. Pressing Enter/Space enters the hovered input field or toggles the hovered button and Q quits the app.
• There's then "Input mode", which is active when in an input field. There the user can write with characters, navigate their text with left/right arrow keys, complete the suggestion with Tab, and leave the mode with Esc. (Enter searches and also leaves the mode, good when finished writing the second input field.)

Hopefully none of this actually needs to be explained as the new help bar, which dynamically displays both modes, explains it pretty simply.

---

I will soon add another commit that reimplements the "DimmedBorder" color, which this time will be used to show focus in or out of InputMode, for easier visual reference.

@0yech @0PandaDEV @Waradu
(@dpajkovic @trintlermint @valyntyler @pierluca @Chaxiraxi @an-Iceberg too if you are interested in giving feedback)
I would love your opinions how this new navigation logic compared to the current master one, do you prefer these simpler and more classic keymaps?

You can test this out with the following:

git clone https://github.com/Necrom4/sbb-tui.git
cd sbb-tui
git checkout feature/remodel-navigation-logic
go run .
# test it

[0PandaDEV]

This feels kind of unintuitive especially that I need to enter into an input field and exit it again without being able to just tab to the next one. Using the tab keys to navigate up and down does kind of make sense, but then I'd also expect the up and down arrow keys to work. Regarding the scrolling I think it's better if there is an actual scroll container with a scrollbar where the user can scroll with their mouse I know it goes against the whole philosophy of a TUI that can be used exclusively with the keyboard but btop for example also allows you to do that, and they support both keyboard navigation and mouse.

[Waradu]

1. When starting it should be in the select mode so you can start typing instantly without pressing enter first.
2. Tab key should still be able to at least go to the next input field (right arrow for autocomplete) because right now just to search a connection I have to do the following: enter -> type -> escape -> arrow right -> enter -> type -> enter instead of: type -> tab -> type -> enter

[Waradu]

@0PandaDEV and me submitting similar feedback at the same time... XD

[Waradu]

Also I had another idea.

There are 2 screens:

1. Configure
2. Results

Configure Screen

• Configure your connection (input fields are stacked vertically) this would also allow to add [FEATURE]: implement Via input field #29 easily.
• It could also show errors below a search input if any etc.
• Pressing enter searches for the connection and goes to the Results screen

Results Screen

• Shows the searched connections.
• Has a small top bar (1 line height) with like location -> via -> via2 -> destination @ time to show the current configuration.
• Escape goes back to configure.
• With --from and --to it would go instantly here.
• Maybe quick actions to swap location with destination?

@Necrom4 @0PandaDEV feedback? questions? ideas?

[Necrom4]

@0PandaDEV

without being able to just tab to the next one

How would be the most natural as a completion keymap and a "multi-results window" scroll keymap to you then?

but then I'd also expect the up and down arrow keys

What would feel natural to you as a keymap to scroll the detailedResult window then? Lazygit implements shift+UpDown arrow (Shitft+j/k aswell), that could be another possiblity.

Regarding the scrolling I think it's better if there is an actual scroll container with a scrollbar

Which scrolling, the one of the left window or right window? Either way I had already created Issues to implement scrolling in both of those (scrollbar on the right and pages for the left)

---

@Waradu

1. When starting it should be in the select mode so you can start typing instantly without pressing enter first.

Yep that was intended and I completely forgot it, thx! (It's "input mode" btw (select is to select an element in the header), so we all know what we're talking about for the rest of this thread).

I also believe the old (master) version allowed faster navigation, but it was very.. "original".
On this one if we use Tab to navigate to the next element in the header, that means we do not need "Selection mode", in which we navigate the header's elements with arrows and vim keys, which was a requested feature. Basically we'd be going back to the original implementation. Can you see an intermediate that actually makes more sense than the original current implementatino?

[Necrom4]

@Waradu

Also I had another idea.

Wooh that would be a huge amount of work, and I wonder honestly how much it would make it better than the current version, except for "Via" which indeed would then be easier to implement. But appart from that I only see more complexity than the current version, so much visually, as in terms of code but also usage.

One very very good thing though, is that in that version every keymap could (still not sure) make sense.
But great and original idea!

[Necrom4]

Btw this PR is a request from multiple people who want to be able to navigate things with Vim keymaps and arrows.

[0PandaDEV]

Honestly the concept of configure and results screen from @Waradu makes the most sense to me, but that would require rewriting the whole UI layout from scratch.

About the Vim bindings I just like the old navigation more maybe this could be solved with a config boolean to activate the vim bindings if that is something a user wants.

[Waradu]

Can you see an intermediate that actually makes more sense than the original current implementatin?

As I had not used Vim for a while, I was a bit confused. This would likely be even more confusing for people who have never used Vim as they are missing the tab key to switch input fields.
So i'd say exactly as you implemented it but just make right arrow auto complete and tab go to the next input field (not next element in the header just the text fields so location -> destination -> location etc. as these are the most frequently edited ones). I'm still not sure if this is the better solution.

I think vim users can adapt to non vim inputs but non vim user can not adapt to vim inputs easily. Maybe add a flag or config option like --vim. It would make the codebase more complex, but it is a valid compromise.

@Necrom4

[Waradu]

Wooh that would be a huge amount of work

Oh yes, it definitely will be.

@Necrom4

[Necrom4]

@0PandaDEV

maybe this could be solved with a config boolean to activate the vim bindings if that is something a user wants.

Unfortunately it would be extremely code (and condition) heavy to implement both "styles" as they share no logic.

@Waradu

This would likely be even more confusing for people who have never used Vim as they are missing the tab key to switch input fields.

No because the Vim keys are just a secondary option to the arrow keys, meaning a user could use this TUI for years without even noticing their existence, they'll never be "lost" because of them.

So i'd say exactly as you implemented it but just make right arrow auto complete and tab go to the next input field

That would baasically be going back to the old (current) navigation, so there would be no reason to have the Selection Mode to Esc then navigate the header, as one can already navigate constantly while in Input Mode.

But I know one thing: Vim users can adapt to non vim inputs, non vim user can not adapt to vim inputs easily. Maybe add a flag or config option like --vim. It would make the codebase more complex, but it is a valid compromise.

90% of TUIs nowadays support Vim keybindings and I myself hate it when they don't have them. The beautiful thing about it is that it's just an extra, so non-vim users never have to be influenced by it, as mentioned above.

---

So what I take from this discussion is that my first implementation ended up being an extremely ergonomic and fast way of using the TUI, that allows the user to do any actions from anywhere in a single navigation mode, while with this PR I wanted to simplify a bit the navigation, normalize it towards a similar style to other TUIs, but I never realized that could ONLY imply a more complex navigation, in terms of number of keys pressed.

This PR hence brings the navigation closer to what most users would find natural, (autocomplete with tab, navigate with arrows, etc), but the dilema is that it's not as ergonomic and also that a "this would have felt more natural to me" conflict, such as tab autocomplete, tab navigate header and tab navigate results, which all feel natural in themselves, but can't coexist.

Now we I'm guessing we should stick with the current version and wait for more feedback, especially from people with opposite opinions. Or we could also try to make this PR's logic a bit more "natural", such as the user opens the TUI in input mode inside the first input box, right autocompletes and tab navigates the header elements. When the user presses Enter, the results appear and he's automatically taken out of the header navigation and into the results, where tab, arrows and j/k allow to scroll the results, while shift+arrows and shift+j/k would scroll the detailed view.
That would be less ergonomic and faster to use than the current version, but it could be more "natural" and accessible. That's up to debate.

Concerning the config layout idea, it would certainly be the cleanest solution, but by far also the least ergonomic, a total opposite of the current system, where we can access all the information and modify everything from a single view and very few key presses away. That's something I wouldn't like to loose, especially if we can find a middle ground in terms of keymaps so we can keep the view the same.

[Necrom4]

PS: Thank you for your reviews, I appreciate it enormously. And sorry for the long 🍑 comment haha, though I believe each point is necessary to be made so all our ideas are understood and we don't repeat ourselves in the future.