Nnn: Sane keybinds and switches

Created on 29 Dec 2019  路  84Comments  路  Source: jarun/nnn

I spent a lot of time today on having some sanity in our keybinds & program switches. Came up with commit 146da5911d8273ce302fb70ddf443cb577f9def4.

Keybinds: https://github.com/jarun/nnn/wiki/Usage#keyboard-and-mouse

Options: https://github.com/jarun/nnn/wiki/Usage#command-line-options

I need all of you to review this and suggest any further changes or discuss if you have anything in mind. From the next release these keys will be fixed.

All 84 comments

I have some job-interview tasks to do. So I'll be a bit busy in the next couple of days.

No problem! We have time for this.

All the best!!!

One idea: if / is filter, it feels very intuitive that ^/ would be some sort of "extended filter" mode, which is "nav-as-you-type" in nnn. I would therefore suggest to keep b for bookmarks and move ^/ to "nav-as-you-type".

I would recommend changing N Context N to 1 2 3 4 Context, because (unless I'm mistaken?) it is hardcoded that we can have only 4 contexts, and the current help message misleads you into thinking that you must press N, while in fact you must press 1 or 2 or 3 or 4.

I would therefore suggest to keep b for bookmarks and move ^/ to "nav-as-you-type"

I did that in an intermediate check-in. There are several points against it:

  • I need to provide a Ctrl shortcut for people who use the nav-as-you-type mode all the time to pick bookmarks. The 2 keys in ^B are too far from each other. I was having difficulties myself.
  • Users are already used to these keys.
  • ^N goes well with _Nav-as-you-type toggle_.
  • The option to start in _nav-as-you-type_ is also -n.

and the current help message misleads you into thinking that you must press N

We can have 1-4 Context 1-4

I was thinking b ^B for bookmarks and ^N ^/ for nav-as-you-type, but I see your reasoning for ^B being difficult to press... 馃 OK I don't have a better suggestion at the moment.

We can have 1-4 Context 1-4

馃憤

We can have 1-4 Context 1-4

Commit c1f168c7cbbf87a8f1acc4ba88e14d68da556392

I noticed a new keybinding and flag v for version sort, and I wanted to ask, did you consider updating the existing algorithm for this scenario, instead of providing a choice for sorting approaches?

I simply noticed that xstricmp is already customized to provide intuitive results for files that are numbered (so we don't have two algorithms for that, which I approve 馃憤), why don't we customize xstricmp further to provide intuitive results when these numbers are versions?

Basically I'd like to propose to merge these two functions in one and remove v toggle.

xstricmp() works with pure-numeric (values), it's crude and not necessarily version sort:

 01/
 1/
 +1/
 02/
 10/
 11/
 101/
 111/
 0aa
  111
 111a
 123
 1111
 aaa
  abc
   abc
 (abc
 ( abc
 [abc
 { abc
 Abc
  Abc
 abc10
abc2

The version sort algo in xstrverscmp() is from standard GLIBC GNU extensions with minor modifications:

 00/
 01/
 02/
 0/
 1/
 10/
 11/
 101/
 111/
  abc
  111
  Abc
  abc
 ( abc
 (abc
 0aa
 111a
 123
 1111
 aaa
 Abc
 abc2
 abc10
  1. As you see from the results, both have distinct purposes. xstricmp() considers locale.
  2. The amount of testing required to test any attempt to merge these functions is significant and (I feel) unnecessary.

Please stick to keybinds and options in this thread. I accidentally closed the issue thinking it was a new one.

@0xACE, @KlzXS, @annagrram need your input on this one. We have to free the keybinds in the next release.

We have to free the keybinds

I hope that means to freeze them, I'm still getting used to things moving around and keybinds seem to be magically changing every few weeks.

I'm okay with keeping them as they are now, but do we maybe want to move range selection to something like Y as other selection options are also bound to that letter? Maybe it's too many things on a single key I don't know. Also what's the reason for archiving being on i? Would it make more sense for it to be on t like tar and sorting by time to be T.

Just throwing things out there. More than anything I think that the freeze needs to happen.

Yes, this thread is meant to freeze the assigned keybinds.

Range selection belongs to the group:

Space ^J  (Un)select           m ^K  Select range, clear
a  Select all

The y stuff are for selection list related functionality. Maybe the following represents that better?

Space ^J  (Un)select           a Select all
m ^K  Select range, clear

Would it make more sense for it to be on t like tar

We support several archive formats by default (whatever's supported on a standard installation). I selected the i from iving, kind of the central letter with a stress.

and sorting by time to be T

This is a very frequent operation. If you see, I have limited capital keybinds to infrequent operations.

Maybe the following represents that better?

This makes the spacing look very bad.

I have re-ordered the help. Please take a look: https://github.com/jarun/nnn/wiki/Usage#keyboard-and-mouse

Physically separating them makes it more obvious, yes. I didn't realize that that's how they were grouped. They seem to make sense when you think about them for a second or two.

@jarun I like the simplicity of the new keybinds, and personally can either get used to new sets or set my own keys, so I don't have a strong opinion on which key does what, as long as it has some logic that I can use when learning it.

We owe this to end-users, who would only want to install and use the utility. If you see the popular terminal FMs are at least a decade old, nnn is pretty young (2y 8m) in that respect. But I think now the initial instability is over and we can arrive at designated keys.

I have changed the option -t (disable dir auto-select in _nav-as-you-type_ mode) to -A to be in sync with other disable options.

I have added R abd ^T for reverse order.

-o open files on Enter

should copy the man page and say only on Enter

@aeosynth I'll update.

Assigned ^F to fire a plugin. Needed a control key to fire plugins instantly.

Assigned key f to jump to first file in dir. Previously this was '.

Would it be a good idea to combine all order toggles under a single key? When user presses the key we will show him the options (like archive options) and he can choose which order to toggle.

Sounds good to me.

Single key to order toggle implemented at 5fb4d637eefc9aa4ca10c79b837f6f8930d9f68b.

Many keys reduced with the single order toggle switch! Can we merge anything else? Of course, if the code is similar (not just functionality).

Now that z is free, how about having z for archiving?

Also, is it a good idea to quit on double escape?

Also, is it a good idea to quit on double escape?

I think not, a habit that especially some vim users might have is pressing Esc several times to get out of prompts, it would be extremely annoying if nnn would exit when it shouldn't...

how about having z for archiving?

Both letters aren't mnemonic for archiving, so I don't have much preference for either of these.

@KlzXS also suggested z sometime back. 2 reasons - z is for zip (one of the longest known archive formats) and being the last letter of the alphabet, it's memorable to some extent. I never forgot z for size for example.

Do you guys think it will make sense to combine selection ops like cp, mv, rm, list and edit together?

Users wouldn't have to remember a lot of keys if we do this. But I am not sure how acceptable the workflow would be. Currently for all these we need to press Shift key. And if you are in filter mode, Esc as well.

If we combine we will have a small key (regular mode) and a control key (for filter mode) and then ask with the initials.

I'm not sure to be honest, combining the order toggles made sense to me because this is not a very frequent operation and it takes more mental power to remember all available the order shortcuts (or need to consult help page); cp, mv, rm and the likes on the other hand are essential, this is probably the main reason I even open nnn, and in this case having two level menu would actually slow me down... 馃

This is just a personal impression of course, I'm happy to hear other opinions.

Yes, forget about it. I also feel removal is going to be a drag.

I am thinking of combining list and edit sel. List first, then ask if user wants to edit and proceed. What do you think?

I am now trying to reduce the second group of shortcuts as you might have noticed already.

After combining selection list and edit, I am thinking of combining fire plugin and pick plugin.

~Pick can just be another option in fire plugin. Maybe just ; followed by ;?~

Press Enter after plugin shortcut to _enter_ plugin directory! ;)

For m ^K Select range, clear I am thinking of changing m to ' (single quote). It gives the idea of grouping together, like characters in a string. (Double quote is shifted, so single quote looks more preferable to me).

Also making F2 and F5 undocumented. Who presses F2 and F5 while working in the terminal? ;)

Press Enter after plugin shortcut to _enter_ plugin directory! ;)

Love this 馃憤

Also making F2 and F5 undocumented. Who presses F2 and F5 while working in the terminal? ;)

Can we drop support of these keys instead of not documenting them?

For m ^K Select range, clear I am thinking of changing m to ' (single quote).

m is _a lot_ easier to type... And for me it was mnemonic to "mark" :) I'm really not very fond of '...

I am thinking of combining list and edit sel. List first, then ask if user wants to edit and proceed. What do you think?

^Y is documented but in fact it's y. But more importantly, this also feels stretched too much where it is not very usable... So say I want to edit the selection - I press y, less is opened with readonly selection, I must press q to exit less, then nnn asks me if I want to edit that selection, then I press y and only then I get editable selection... that's a lot of "thens" 馃檪

Can we drop support of these keys instead of not documenting them?

Sure!

m is a lot easier to type... And for me it was mnemonic to "mark" :) I'm really not very fond of '...

OK. We keep it m. I'll document as _mark range/clear_

this also feels stretched too much

I think generally people would want to see the list first and then edit it. I will think more about this flow.

I think generally people would want to see the list first and then edit it. I will think more about this flow.

Personally I could even live with _only_ edit functionality, because when I edit, I get a nice text editor opened with a list of selected files, and I can edit it and save, or I can close the editor without saving (if I only wanted to see the list without saving). For my own use-case, having two hotkeys (or two modes) to open the same file with two different apps is excessive. The same applies for p and e, I never use p, because in e I can not only preview text, I can also navigate, copy, and edit if necessary.

I guess introduction of two keys (p and e, or preview and edit selection) was made for people who use some very heavy editors that take long time to start?

The same applies for p and e

p is needed. You can use the pager as the opener. @0xACE does that.

Yes, I think only edit option should be fine.

I have modified the edit selection workflow to edit any selection in current instance. If none selected, it would try to list the selection file. I blocked editing the selection file because it should be edited from the instance in which the files were added.

For edit sel I set the keybind ^W... w for write loosely.

I have modified the edit selection workflow to edit any selection in current instance. If none selected, it would try to list the selection file. I blocked editing the selection file because it should be edited from the instance in which the files were added.

I like, and it makes sense. What do you think about not asking 0 selected, list selection file? and just listing selection immediately? In other words, if selection is opened in EDITOR that means it's selection from this instance and I can preview it and even edit if I want, but if selection is opened in PAGER then this means that the current instance has no selection and I'm previewing selection from another instance.

My reasoning is, if user presses this hotkey, they _want_ to see selection, extra question might be counter-productive in this case.

My reasoning is, if user presses this hotkey, they want to see selection, extra question might be counter-productive in this case.

I felt the same, but wanted a second opinion as they are visually different. Thanks! I'll remove the question.

@maximbaz p and e are from noice and I kept it the way it was.

@0xACE I was thinking we can probably now remove these 2 keys:

  • p: I remember your notes from here. Can you explore how it can be set as opener? Otherwise, can we document how user can set it as a plugin? We also have nuke in place now where this can go.

  • e: This is the purpose of having NNN_USE_EDITOR. Otherwise, again, user can have a plugin.

And for both the cases, for occasional disaster handling when you are looking for a fallback, there's always Open with...

I am removing both p and e. There are several ways to view and edit files as I mentioned above.

Can we teach Enter to open _empty files_ in EDITOR when NNN_USE_EDITOR is set? This was probably my only use-case when I pressed e instead of Enter, because pressing Enter on an empty file would do nothing and say empty: edit or open with.

We can do that. One question, if we use a CLI-only opener (with option -c), for text files shall we still respect NNN_USE_EDITOR if it is defined?

Not respecting NNN_USE_EDITOR has its advantages... e.g. nuke opens man pages in troff. So I can edit and view. The editor would just let me edit, no preview. Only in case of an empty file, we would have to use "open with"

I haven't used -c yet but what you say makes sense, plus it seems -c even before already took priority over NNN_USE_EDITOR:

https://github.com/jarun/nnn/blob/5bc20f1460ddf02e778c1670c249655c6e3168e8/plugins/nuke#L14-L16

Yes, I've followed it from the beginning. Just needed a second opinion,

A better key for lock terminal?

The latest commit works well, but I'll be testing more.

L Lock terminal - wanted to confirm, is this a useful feature that warrants reserving it's hotkey? I'm just asking because it doesn't even seem to work in my terminal or I just don't know what to expect from it (pressing L hangs my terminal forever with writing the messages below in infinite loop, doesn't react on Ctrl+C, can only be stopped by killing the terminal (?))

$ n
This tty (pts/8) is not a virtual console.


The pts/8 is now locked by maximbaz.
Authentication failure.


The pts/8 is now locked by maximbaz.
Authentication failure.


The pts/8 is now locked by maximbaz.
Authentication failure.

....

UPDATE: hehe we are thinking the same thing 馃槃

UPDATE: hehe we are thinking the same thing

Yes, I was taken by surprise there.

The feature is disabled by default. We need it so users can lock the terminal when they want. Works just fine for me.

How about the key 0? To convey show 0 info?

The feature is disabled by default.

Do you mean you expect L to do nothing unless user configures something? This definitely isn't the case, I searched around, it seems vlock was merged in kbd some many years ago, and kbd in turn is a systemd dependency - so _everywhere_ where systemd is present, vlock is present as well, and it doesn't work because vlock apparently can only work in virtual console.

I like 0 because this key is far away from everything else, a couple of times already I accidentally pressed L and was forced to abandon my work in nnn and kill terminal and restart from scratch.

I meant timeout is not set. But if you press the key expect something. I'll set 0.

Done.

Nice. So many keys were made free, I feel like we should re-evaluate everything once again 馃檪 For example, does it make sense to have capital P, V, X when lowercase are available? So that we don't need to press Shift anymore.

yes, that would be cool!

maybe reassign e to edit sel?

Yes!

What is your general approach for capital and Ctrl keys, do you have some guideline? For example, we have "delete sel" and "delete entry", one can be x (probably sel if "copy sel" and "move sel" will be lowercase), one can be X (delete entry) and ^X is assigned to ... most used?

I don't know if we even need Shift+X when we already have Ctrl+X, I'm more interested to understand how you think when assigning keys.

I keep the ^ shortcuts for people who use nav-as-you-type. ^ chars break away from filterentries().

We should rename "Order toggle". Maybe "Sort by"?

"Sort by" is not bad, it helped to know that those keys are in fact toggles, i.e. if I select the same sort twice, it will be reversed. Maybe "Sort toggles"?

Yes!

How about ^F for file details?

Both sound very intuitive for me, go for ^F 馃憤

Cool!

From nav-as-you-type mode, Shift keys are horrible. You have to Esc to come out and then press 2 more keys. ^ keys are as good as a single key.

Looks like we don't have any compelling shift key anymore.

Makes sense.

I feel like "copy/move/delete sel" are so important operations that they absolutely must have Ctrl shortcuts as well, otherwise nav-as-you-type is not as powerful mode.

Ideally we would assign ^P, ^V, ^X keys to them in addition to p, v, x, but this conflicts with other existing shortcuts (which we could maybe think to remap?)

Let's try!

^V Copy/move sel as can have w ^W coming from write and cp/mv.

Delete entry needs a ^ key. What would it be?

And plugin needs a ^ key too! I have to go to sleep now. 4 here. Think about these.

There you go: https://github.com/jarun/nnn/pull/436

As a user I particularly like how even less keys there are now to remember when Ctrl keys use the same letter as regular mapping (e.g. p ^P, m ^M, etc.)

I think we can settle with:

D - file details
f ^F - Fire plugin

Let's have:

f ^F - file details
; ^S - select plugin

I am pushing the changes. Please review.

Please review commit 1b252b6ecbb8e754069a33b6cf585e41f705604a.

Nice catch about ^;, I'll play a bit more just to confirm your finding that it won't be possible to support it.

Delete with prompt is nice, one ask - in the specific case when I select a couple of files, press x and choose c (current) - can we not refresh screen, so that selection marker + is preserved?

Otherwise I think it already looks very very pleasant to me. 馃憤

in the specific case when I select a couple of files, press x and choose c (current) - can we not refresh screen, so that selection marker + is preserved?

We have to remove the entry that's deleted, so we need to reload the directory. Also there are other reasons, say there was a link to the file, that gets orphaned and so on. When you change the directory contents, we should always reload. If it helps, I don't end the selection so you can continue selecting.

I can now see that ; and ^; are both recorded by getch() as just ;, once again - nice catch :)

I have no more suggestions for the key bindings, everything looks very reasonable to me.

everything looks very reasonable to me.

Same here! Fewer keybinds, quite meaningful...

@annagrram @KlzXS please review the latest set of keybinds. We are making a release tomorrow.

Current set:

         Up k  Up                PgUp ^U  Scroll up
         Dn j  Down              PgDn ^D  Scroll down
         Lt h  Parent            ~ ` @ -  HOME, /, start, last
     Ret Rt l  Open                    '  First file
         g ^A  Top                     .  Toggle hidden
         G ^E  End                     0  Lock terminal
         b ^/  Bookmark key            ,  Pin CWD
          1-4  Context 1-4        (B)Tab  Cycle context
            /  Filter                 ^N  Nav-as-you-type toggle
          Esc  Exit prompt            ^L  Redraw/clear prompt
            ?  Help, conf             ^G  QuitCD
         Q ^Q  Quit                    q  Quit context
 FILES
         o ^O  Open with...            n  Create new/link
         f ^F  File details            d  Detail view toggle
           ^R  Rename/dup              r  Batch rename
            z  Archive                 *  Toggle exe
     Space ^J  (Un)select           m ^K  Mark range/clear
         p ^P  Copy sel here           a  Select all
         v ^V  Move sel here        w ^W  Copy/move sel as
         x ^X  Delete                  e  Edit sel
 MISC
         ; ^S  Select plugin           =  Launch app
         ! ^]  Shell                   ]  Cmd prompt
            c  Connect remote          u  Unmount
         t ^T  Sort toggles            s  Manage session
optional args:
 -a      use access time
 -A      no dir auto-select
 -b key  open bookmark key
 -c      cli-only opener
 -d      detail mode
 -E      use EDITOR for undetached edits
 -g      regex filters [default: string]
 -H      show hidden files
 -K      detect key collision
 -n      nav-as-you-type mode
 -o      open files only on Enter
 -p file selection file [stdout if '-']
 -Q      no quit confirmation
 -r      use advcpmv patched cp, mv
 -R      no rollover at edges
 -s name load session by name
 -S      du mode
 -v      version sort
 -V      show version
 -x      notis, sel to system clipboard
 -h      show help

Closing the defect.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

deadpyxel picture deadpyxel  路  5Comments

kuntau picture kuntau  路  3Comments

lenormf picture lenormf  路  6Comments

snide picture snide  路  6Comments

Wuzado picture Wuzado  路  9Comments