You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 (#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.
The text was updated successfully, but these errors were encountered:
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:
modal: true
configured (or some other flag if this is implemented and is non-breaking)NAV
mode, orNORMAL
mode (not sure if the vim term is a good one here) This would correspond to what is currently referred to ascommand
mode./
keySEARCH
mode. Verbs are not available from this mode, meaning the user can search for a literal:
character.alt-j/k
are still viableEsc
and is placed back intoNAV
mode.Enter
/
).Esc
andj/k
to navigate to the each of the items, staging each one:
fromNAV
mode to enterCOMMAND
moderm<Enter>
to call their remove file command.Esc
when inNAV
mode clears the current search.h/l
for this purpose:h
several times. This has the exact same behavior asEsc
, except that the search terms that are cleared are remembered.l
to perform the inverse ofh
: sequentially restore the cleared search terms and focus back into the previously selected foldersThere is this issue (#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.The text was updated successfully, but these errors were encountered: