Modal mode enhancement

[brettmitchelldev]

The modal mode that comes with broot is helpful for logically separating out some of the interactions in the application, but not all of them. Specifically, searching for a filesystem item and entering a verb name are not distinguished from each other. I think there would be a lot of value in a modal feature that separates navigation, searching, and commands into distinct modes.

In addition, when it comes to keybindings, there isn't a semantic way to designate a mode, but at least for searchable key combinations (no modifiers) we are already able to define modal keybindings due to the fact that a key will be directed to the search input in input mode, but will be picked up as a command keypress in the existing command mode. I do think that there is benefit, though, to allowing the user to somehow designate modal associations with keys.

Both of these improvements would be invaluable to my personal workflow, and I'm curious to know if any others would benefit from this as well.

Example user interaction:

• User opens broot with modal: true configured (or some other flag if this is implemented and is non-breaking)
• User is immediately placed in NAV mode, or NORMAL mode (not sure if the vim term is a good one here) This would correspond to what is currently referred to as command mode.
  • In this mode, the user may navigate with j/k
  • Any keybindings designated as available in this mode may be used here. Staging, moving, renaming, etc. become fairly quick to do
• User presses the / key
  • They are now placed into SEARCH mode. Verbs are not available from this mode, meaning the user can search for a literal : character.
  • As the user types, broot filters the filesystem as usual.
  • The user can still have keybindings in this mode; alt-j/k are still viable
• User has finished entering their search term, and is ready to select a directory they see in the results
  • User presses Esc and is placed back into NAV mode.
  • Their search term remains and is still visible
• User navigates down to the directory they would like to select and presses Enter
• broot focuses that folder with the same behavior as currently exists (search term is saved in a stack, but the search term for the newly selected folder starts empty)
• User searches for a couple of files with the same technique (using /).
• When the files appear, the user uses Esc and j/k to navigate to the each of the items, staging each one
• After staging both files, the user types : from NAV mode to enter COMMAND mode
  • A prompt appears, temporarily overlaying the search input, for the user to enter a command
  • The user types rm<Enter> to call their remove file command.
  • As the user types, suggestions are provided as they type as is the current behavior
• User is now done with this folder, and is ready to go back to the parent
  • In this situation, the default behavior could be that Esc when in NAV mode clears the current search.
  • Another possible but more involved option is to use h/l for this purpose:
    • User navigates through several folders, leaving each with its own search term
    • User presses h several times. This has the exact same behavior as Esc, except that the search terms that are cleared are remembered.
    • User can now press l to perform the inverse of h: sequentially restore the cleared search terms and focus back into the previously selected folders

---

There is this issue (https://github.com/Canop/broot/issues/185), in which it appears the current form of modal mode was discussed and implemented. It seems like the escape key is the most troublesome issue; it has different meanings in different contexts. Part of the issue, I believe, may be due to the fact that searching and entering commands are not distinct modes.

Fully resolving the concern, however, may involve creating a bind-able interaction for each distinct situation where the Esc key is used. I believe this would be useful anyways, even if an expanded modal mode is not considered a good idea.

[muellan]

+1