Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults

[David Ramsey]

Brand Huntsman:
> My understanding is that you want ^H to always be do_backspace for
> everyone on every system, and "bind ^H ..." should fail. Is that not
> correct?

That is not correct.  "bind ^H" should work as it does now.

Having "bind ^H [some key]" and "bind Bsp [some other key]" on the same
system is the problematic case.  The aforementioned git commit doesn't
add a "Bsp" binding, but if its comment is correct, it's trying to allow
you to bind "^H" *without* binding Backspace to what you bound "^H" to,
which is along similar lines.

If Backspace generates ^?, this will work; if Backspace generates ^H,
this will *not* work, because the latter is indistinguishable from an
actual Ctrl-H.  And there's no way to know offhand which value Backspace
generates, so this may work, or not, depending on the terminal.  So what
I'm suggesting is the approach of "bind ^H if you will, but don't expect
the Backspace key to do something other than what you bound ^H to do,
since there's no way to guarantee that".

The same applies to ^I and Tab, and ^M and Enter.  I've tested the last
of these, and if Enter generates ^M, the two keys *are*
indistinguishable, at least on my system.  Specifically, adding "bind ^M
curpos all" to my nanorc makes both Ctrl-M and Enter display the cursor
position.

Having every key bindable is a nice goal, but due to the limitations of
control characters under curses, it is not possible to bind all control
keys that generate control characters rather than escape sequences,
since there are only 32 control characters, but there are more possible
control sequences.  There are also some aliases (e.g. Ctrl-` acting the
same as Ctrl-Space), but they're not guaranteed to work consistently on
all terminals, either.  This kind of thing is why nano uses Meta
sequences a lot more, since they don't have these issues.