FS#74379 - [ncurses] Missing "configure" option --with-xterm-kbs=del

Attached to Project: Arch Linux
Opened by Hong-Leong Ong (hongleong) - Thursday, 07 April 2022, 04:02 GMT
Last edited by David Runge (dvzrv) - Thursday, 05 May 2022, 07:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To David Runge (dvzrv)
Felix Yan (felixonmars)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: The "dialog" package treats BACKSPACE key as DELETE in the middle of a word.

Additional info:
* package version: ncurses 6.3-2, dialog 1:1.3_20220117-1

Steps to reproduce:
1. Run "dialog --inputbox Input 10 30"
2. Enter the word "abc" into the inputbox
3. Hit the LEFT-ARROW key twice to move the cursor over "b"
4. Hitting the BACKSPACE key deletes "b" instead of "a", essentially functioning like the DELETE key.

Workaround:
$ infocmp | sed -e 's/kbs=^H/kbs=^?/' >foo; tic foo

Analysis by Dialog's author, Thomas E. Dickey:

== BEGIN QUOTE ==

When I implemented the current scheme of key-bindings in 2005,
it seems that I preserved several pre-existing hard-coded definitions,
where one would expect just the definition in curses. But by doing
that, it's possible to have conflicting bindings.

Here's a chunk from doing that (i.e., replacing "8" from the source):

- case 8:
- case KEY_BACKSPACE:
- if (offset) {
- offset--;
- len--;
- for (i = offset; i <= len; i++)
- input[i] = input[i + 1];
- }
- break;

What I have now is

calendar.c:693: DLG_KEYS_DATA( DLGK_GRID_LEFT, CHR_BACKSPACE ),
dialog.h:164:#define CHR_BACKSPACE DLG_CTRL('H')
dlg_keys.h:122: DLG_KEYS_DATA( DLGK_DELETE_LEFT, CHR_BACKSPACE ), \
rangebox.c:175: DLG_KEYS_DATA( DLGK_FIELD_PREV, CHR_BACKSPACE ),
timebox.c:157: DLG_KEYS_DATA( DLGK_FIELD_PREV, CHR_BACKSPACE ),

and that dlg_keys.h definition is what you're using:

/* ^U == 21 */
#define INPUTSTR_BINDINGS \
DLG_KEYS_DATA( DLGK_BEGIN, KEY_HOME ), \
DLG_KEYS_DATA( DLGK_DELETE_ALL, CHR_KILL ), \
DLG_KEYS_DATA( DLGK_DELETE_LEFT, CHR_BACKSPACE ), \
DLG_KEYS_DATA( DLGK_DELETE_LEFT, KEY_BACKSPACE ), \
DLG_KEYS_DATA( DLGK_DELETE_RIGHT, CHR_DELETE ), \
DLG_KEYS_DATA( DLGK_DELETE_RIGHT, KEY_DC ), \
DLG_KEYS_DATA( DLGK_FINAL, KEY_END ), \
DLG_KEYS_DATA( DLGK_GRID_LEFT, KEY_LEFT ), \
DLG_KEYS_DATA( DLGK_GRID_RIGHT, KEY_RIGHT )

However, the KEY_xxx symbols (from curses) override the CHR_xxx symbols.

Using infocmp, you can see what kbs (KEY_BACKSPACE) is set to.

I can see by that, that Arch has kbs=^H for xterm, which is incorrect
(for Linux...).

But CHR_DELETE is ^?, which is not mapped in curses.

DLG_KEYS_DATA( DLGK_DELETE_RIGHT, CHR_DELETE ), \

The value used for kbs is a configure option because Linux differs from
almost everyone else (Cygwin does imitate Linux):

--with-xterm-kbs=XXX
Configure xterm's terminfo entries to use either BS (^H, i.e., ASCII
backspace) or DEL (^?, or 127). XXX can be BS (or bs, 8) or DEL
(or del, 127).

During installation, the makefile and scripts modifies the "xterm+kbs"
terminfo entry to use this setting.

xterm attempts to use the system's convention for the "backspace" key.
It looks like Arch didn't use the configure option:

https://github.com/archlinux/svntogit-packages/blob/packages/ncurses/trunk/PKGBUILD

fwiw, Debian gets that right:

https://salsa.debian.org/debian/ncurses/-/blob/master/debian/rules

I'd have done the same for the myriad of xterm-lookalikes, but most of
those are hard-coded to imitate xterm running on Linux (and they generally
are misconfigured in their ports to the BSDs and Unix platforms).

> May I know if this is expected behaviour? Is there any way I can make it do
> an actual BACKSPACE instead of DELETE?

As a workaround (a bug report to Arch might help), you can do something like

infocmp | sed -e 's/kbs=^H/kbs=^?/' >foo; tic foo

== END QUOTE ==
This task depends upon

Closed by  David Runge (dvzrv)
Thursday, 05 May 2022, 07:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with ncurses 6.3-3
Comment by David Runge (dvzrv) - Thursday, 28 April 2022, 09:52 GMT
@hongleong: Thanks for the ticket and for reaching out to upstream as well!

I'll fix this in a pkgrel bump.
Comment by David Runge (dvzrv) - Thursday, 28 April 2022, 10:02 GMT
Please check whether ncurses 6.3-3 in [testing] fixes this for you.
Comment by Hong-Leong Ong (hongleong) - Thursday, 05 May 2022, 07:16 GMT
@David, yes, ncurses 6.3-3 fixed the issue. Thanks for your help! :)

Loading...