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

[David Niklas]

-----BEGIN PGP SIGNED MESSAGE-----
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
idea.
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.

Thanks,
David
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEL2N7+xWmVOJDQxWGm3XCrhg2YP8FAl0BfrcACgkQm3XCrhg2
YP90dBAA1QYBxyU9hKVBP2QFhRlFlbH+diJU+jawtg3zWROLTRhrrqzhWt6jgcAB
OOjdfUgmM7s0znPfeScKtlsmZWPwu0MKtK/DWqNOiS1Qw6jkOzbv8tTQPQbC4Y3n
V/lGBLZ8S9YygM2OsYgNKnDeIKSrNReImlIdi28oZeA8NI2fF4tD5PKopcIhz/bV
JmPhCaqil2WfcBe07sAMiYrBLY9vpVO6QbO5WqvdqwM036e46BDgWAUvRIJoSQ+Y
737AP3KhJg/1Z4yPoeITR40uUMdmSnqXLVNJPuU7bt3ZugrAcnG1L4ixLKHPy2wH
Mj+ksS6WTjOW+2axthkv2StUo86JBp46buUHgCgSvTVZzJ+HpYwbrcbBgvDD18BP
x9+ZDd7vSc9jc5jIsNXcHw78bN3iS2f+7e8EdUBWgr5h881g6LUOx+yA2Zx8QwA1
KblSUD6jpDphvAo8R1jV/UKqDGP62RcfLxfzU5T3zXUkoIB7Q+PmhtjVSkgzNRrt
mR0vCH4lik0W8TwNwtTm3owY/AK3HMjkcT243l4QOJuMe0KjCQy9Rq9b2yf/r/Ne
sucta+UfvMux2eE/DIBrlVrLh/ZzjrHIbQwIsh/3zXcYeNHIGav4Uzl8XcT2JNnV
m61eyVkSJWoo7kXl4909YcUfvgmo08HYhkC0MbHrvU65j7WxuOw=
=aj9T
-----END PGP SIGNATURE-----