[Top][All Lists]

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

Re: [Nano-devel] proposal to free up some key bindings

From: David Niklas
Subject: Re: [Nano-devel] proposal to free up some key bindings
Date: Wed, 12 Jun 2019 18:37:43 -0400

Hash: SHA256

On Tue, 11 Jun 2019 10:56:49 +0200
Benno Schulenberg <address@hidden> wrote:
> Op 10-06-19 om 17:37 schreef David Niklas:
> > Benno, you've said several times that we have too many keys bound.  
> I have said no such thing.  I've said that there are almost no bindable
> keystrokes left. 

I was quoting you indirectly from memory. Out of curiosity, both
statements look to convey the same information, what's so bad about my
version? Isn't it close enough?

> But... do we need any more keystrokes at the moment?

No, but it always helps to have some leftover for later.

> > You said that my proposal was "an idea". That was almost 5 months ago.
> > 
> > Can you take this to the next level and actually seriously consider
> > it?  
> I said it /might/ be an idea.

My mistake, I'm used to the above 2 quotes being used as equals.

> But looking at it again, it won't work.
> The whitespace toggle (M-P) and the auto-indentation toggle (M-I) need
> to be single keystrokes -- having them as two-stroke functions would be
> awkward.  For me the same goes for the linenumbers and softwrap toggles
> (M-N and M-S).  And, for the people that use them, probably the same for
> M-M and M-L.  The other seven toggles are maybe used so little that it
> wouldn't be a problem if they became two-stroke toggles.  But... if
> there are people who need some simple keystrokes for customization,
> then let them choose which toggles they can do without and rebind
> those keys.  Personally, I have rebound M-K, and if needed I could
> do without the M-O, M-H, M-C and M-X toggles.

Um, you're ignoring the fact that when you run out of a limited resource
(key-bindings), you allocate that resource in a wiser fashion, hence my
I'm not saying that M-I *must go*. Or any of the others. I'm saying that
we should talk about which ones would be useful to relegate to a
sub-menu so that future functions could use those key-bindings.

Idea B:
Of course, just creating the sub-menu would allow each person to make
whatever reassignments they want, without the fear of loosing access to
any of the toggles.

> But true, a Toggles menu could be an additional way of accessing the
> toggles instead of a replacement of the current bindings.
> The advantage of having a Toggles menu would be that the help lines
> would show (very concisely) which toggles are available, without having
> to consult ^G M-/.  But at the moment there are thirteen toggles, and
> in a default 80-column only twelve fit on the help lines.  Which one
> to choose to /not/ show in that case?

Think up the various use cases of nano (email?, coding, text editing), and
choose the least used one.
Here's some really good ones that I rarely, if ever, use and can't
imagine a use case that would require frequent toggling:
M-O More space          Probably only set once.
M-X Toggle help         Probably only set once.
M-M Mouse support       Probably only set once.
M-N DOS/Mac conv.       Maybe used, but only set once most likely.
M-Z Suspend support     Probably only set once.

Others: Feel free to shoot these down if you use them often. Give me your
use case too, it would be interesting.

> Anyway, it will have to wait until after the Tools menu is implemented,
> so that M-T will be freed up so that it can be reused for a Toggles
> menu.
> Benno

Ah, I understand why you dropped the subject now.



reply via email to

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