nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] key bind menus


From: Benno Schulenberg
Subject: Re: [Nano-devel] key bind menus
Date: Mon, 23 Oct 2017 21:27:22 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0


Op 18-10-2017 om 23:53 schreef Brand Huntsman:
On Wed, 18 Oct 2017 21:57:30 +0200 Benno Schulenberg <address@hidden> wrote:
There is the meta menu "all".  See the manual.

That would also bind a key to MHELP and MYESNO. I tested and it doesn't cause any issues in those menus, other than needing to bind a different function to help menu _after_ binding the other to all menus.

I don't get what you mean.  Please give example commands.

Which functions would you want to rebind in those menus? Apart from Cancel there is nothing that can be rebound there.

^X would be nice since I always press it before ^C. But someone else who uses F2 instead of ^X might want that to cancel, allowing those menus in nanorc lets the user choose. I didn't even know about the F-key bindings until I injured my left hand recently, and F2/3 to exit and save helped a lot. It appears that "bind F2 cancel all\nbind F2 exit all" actually works and calls cancel or exit when F2 is pressed. Is this behavior intentional?

There is no deep, thought-out concept behind the rebinding code.
It seems to allow the things that are needed.

It could lead to some issues if the user doesn't first unbind a built-in binding before rebinding it.

I'm don't think unbinding a key is ever necessary before binding
it to something else -- the binding code does this automatically.

Maybe your example works because no menu can contain both an Exit
and a Cancel -- when this does seem to be the case, the "Cancel"
is just an alias for Exit, added for convenience.

It appears the menus set in add_to_funcs() determines if the function appears in the help for any given menu. The do_cut_text_void function is only in MMAIN
and doesn't appear in the help for prompts that can use it.

Adding ^K (and then also ^U) to the help of every prompt would
clutter the help lines.  The user wants to know what keystrokes
actually affect the Search, or the Read or the Write, not how to
edit what is typed at the prompt.  ^A and ^E, ^Left and ^Right,
and so on, are not explained either.

Benno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]