nano-devel
[Top][All Lists]
Advanced

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

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


From: David Ramsey
Subject: Re: [Nano-devel] [RFC] is it time to break free from the Pico defaults
Date: Wed, 19 Dec 2018 10:45:24 -0600

Benno Schulenberg:
> 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.

Linux console, xterm, urxvt: 107
rxvt, urxvt with TERM=xterm-256color, konsole, xfce4-terminal, qterminal: 7f

> 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.

Indeed.

> Maybe it's better to drop the whole keypad() call and just
> use escape sequences only.

That will break the mouse support, which requires keypad().

> 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.

That's what I thought.  But if that's the case, why is it only done
under the BSDs and MacOS, seeing as some Linux machines do it as well?

> 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.)

Okay.

> 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.

A binding that only works when Ctrl-H and Backspace don't generate the
same code (a situation which is currently impossible to predict) sets
off the warning bells in my head.  Differing escape sequences can be
compensated for (up to a point) for portability's sake, but this can't,
and for similar reasons as Ctrl-I/Tab and Ctrl-M/Enter.

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

Thank you.



reply via email to

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