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

[Benno Schulenberg]

Op 19-12-18 om 01:47 schreef David Ramsey:
> Benno Schulenberg:
>> For me, running 'nano --ignore -d', the <Delete> and <Backspace> keys
>> work normally, on Linux console, on xterm, on rxvt, on urxvt, and on
>> xfce4-terminal.  :| (Only when I also use -K do <Del> and <Bsp> start
>> to do the same thing: delete rightward.)
> 
> It sounds as though your terminals are the exact kind of broken needed
> for the -d option.

What?  ...  Not at all.  When the terminal and the TERM variable and
ncurses and the terminfo database are all in harmony, then -d *should not*
have any effect, because in that case, whatever the <Backspace> key actually
produces, ncurses will translate it and nano will see KEY_BACKSPACE, and
whatever the <Delete> key actually produces, ncurses will translate it, and
nano will see KEY_DC.  And KEY_BACKSPACE is always bound to do_backspace(),
and KEY_DC is always bound to do_delete() (when there is no "bind Del..."
in a nanorc), the -d option does not influence that.  The -d option only
has any effect when somehow the DEL_CODE (0x7F, ASCII DEL, ^?, octal 177)
gets past ncurses *untranslated*, and as far as I can see this can only
happen when there is some mismatch between terminal/TERM/terminfo/ncurses,
*or* -K is used.

> Here, "infocmp | grep -e kbs -e kdc" gives:
> 
> xterm, rxvt, konsole, xfce4-terminal, qterminal: kbs=^H, kdch1=\E[3~

Ah.  When you remove the #ifdef around the "hex codes" fragment in
src/winio.c, and then run nano in those terminals and you type <Bsp>,
does it report 107 hex (KEY_BACKSPACE)?  Or does it in fact report 7f
hex (DEL_CODE)?  If the latter, then the terminal description does
not match what the terminal actually produces.

> In any case, I figure that -d and -K are options that you shouldn't use
> unless nano doesn't work properly without them;

True.  But you know I would prefer to get rid of those options.  When
ssh'ing to a different machine, we can't count on it having a correct
terminfo database, so nano will have to interpret escape sequences
anyway.  Maybe it's better to drop the whole keypad() call and just
use escape sequences only.

> and, due to the
> aforementioned inconsistencies with Backspace, fiddling around with
> Backspace is just asking for trouble.
> 
> Regarding the latter, why is commit e8a5665 necessary?  I'm aware of the
> commit's description, but... trying to bind Ctrl-H and Backspace
> separately seems like a problem waiting to happen in terminals where
> they generate the same keystroke

If Ctrl+H and <Backspace> produce the exact same keycode, then there
is no problem: when the terminfo database is correct, the code will
be translated by ncurses to KEY_BACKSPACE (107) and will be bound to
do_backspace().  But when those two keystrokes (Ctrl+H and <Backspace>)
*do* produce different codes, then it becomes possible to bind them to
different things.  Yes, it's confusing, but it can't be helped.

> Also, binding
> Ctrl-H to word-cutting while binding Backspace to backspacing sounds
> like something we shouldn't encourage, given that it might lead users to
> think they can bind, say, Ctrl-I and Tab separately.

Tab cannot be rebound.  If the user tries: "bind Tab..." produces an
error message.  So does "bind Enter...".  Nor can Backspace or Bsp
be rebound.  (As an exception, only "Ins" and "Del" can be rebound.)

So it's not that ^H and <Bsp> can be bound separately, it's just that
^H can be bound to something other than do_backspace() *if* the <Bsp>
key does not produce the same code as Ctrl+H.

> (The now-closed
> bug #54868, which referenced it, may have lacked information. but
> wouldn't it be better to deal with things like it by requiring *some*
> contact information in bug reports?)

Okay.  I've changed the permissions on Savannah so that only logged-in
users can report a bug for nano.

Benno

signature.asc
Description: OpenPGP digital signature