Re: [PATCH] Change <delete> to delete forward in the editor menu.

Thomas Dickey <[email protected]> Sun, 2 Aug 2026 15:20:53 -0400
Newsgroups gmane.mail.mutt.devel
Message-ID <[email protected]>
--8e86EYnzsf3lbPBd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 02, 2026 at 01:29:29PM -0300, Jim wrote:
> On Sun, Aug  2, 2026 at 05:13 (-0400), Thomas Dickey wrote:
>=20
> > On Sat, Aug 01, 2026 at 09:53:37PM -0300, Jim via Mutt-dev wrote:
> >> On Sat, Aug  1, 2026 at 21:47 (-0300), Jim wrote:
>=20
> >>> On Sat, Aug  1, 2026 at 18:34 (-0400), Kurt Hackenberg wrote:
>=20
> >>>> On Sat, Aug 01, 2026 at 18:05 -0300, Jim via Mutt-dev wrote:
>=20
> >>>>>> Moreover, Jim also said that the Delete key of
> >>>>>> his keyboard sends ^H (instead of the usual escape sequence).
>=20
> >>>>> Or so says my shell when I type Ctrl-V <delete key>.
>=20
> >>>> That's with X and a terminal emulator?
>=20
> >>> Yes.  Specifically, urxvt.  Same in xterm.
>=20
> >>>> That is peculiar. I would look into why that ^H happens.  Something
> >>>> strange in X keyboard input, I guess.  Do you configure that keyboard
> >>>> input in any way, maybe through xmodmap?
>=20
> >>> No.  A few messages ago (I didn't realize my ideas about "delete" mea=
ning
> >>> "delete backwards" were going to take on a life of their own) I menti=
oned
> >>> that back in 2004 I used to swap backspace and delete with xmodmap, b=
ut
> >>> since then I haven't had to do it.  I may have known at the time what
> >>> changed, but if I did, that memory is long gone.
>=20
> >>>> What does xev say about the Delete key?
>=20
> >>> It says
>=20
> >>> KeyPress event, serial 33, synthetic NO, window 0x5200001,
> >>> root 0x6ab, subw 0x0, time 607437571, (105,127), root:(286,252),
> >>> state 0x0, keycode 119 (keysym 0xffff, Delete), same_screen YES,
> >>> XLookupString gives 1 bytes: (7f) "=7F"
> >>> XmbLookupString gives 1 bytes: (7f) "=7F"
> >>> XFilterEvent returns: False
>=20
> >>> which makes a certain amount of sense (to me, anyway): the "delete" k=
ey
> >>> sends the "Delete" keysym and XLookupString turns that into the ASCII=
 DEL
> >>> character.
>=20
>=20
> >>> Bonus information:
>=20
> >>> My termlib entry says  kdch1=3D\E[3~.
>=20
> >>> Interestingly (or not) with xfce4-terminal, at my shell prompt,
> >>> Ctrl-V <delete>
> >>> outputs <Esc>[3~, and kdch1 is the same \E[3~ there.
>=20
> >> "Mystery" (partially?) solved.  I see that (presumably since 2004 or s=
o) I
> >> have X resources for xterm
> >> XTerm*backspacekey:	\177
> >> XTerm*deletekey:	\010
>=20
> > those aren't recognized by xterm (see manpage)
>=20
> Looking in my X resources file, I see
>=20
> XTerm.vt100.translations: #override \
>                 <Key>BackSpace: string(\177) \n\
>                 <Key>Delete: string(\010)
>=20
> (which I didn't notice when I quickly looked).
>=20
> Some people might wonder about the ones I mentioned above; the comment
> in my file is revealing:
>=20
> ! Ironically, this works in rxvt and aterm, but not xterm!
> XTerm*backspacekey: \177
> XTerm*deletekey: \010
>=20
> The "mystery" is possible more solved now.

yes... rxvt developers did that in the 1990s, claiming (incorrectly) that
there was considerable overlap.  There sort-of was, but in that overlap
there were differences which led to lots of bug reports.

In a quick check, rxvt-unicode removed that in March 2004
(Lehmann's first commit was in November 2003)

--=20
Thomas E. Dickey <[email protected]>
https://invisible-island.net

--8e86EYnzsf3lbPBd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmpvmJEACgkQzCr0RyFn
vgMCnAwAwhu53oeVBVFXL0UvemGgdQ65e1Pl205TiFUWXGlVuc7b+vQgA/NvHNbS
hj4IHxUVMAZG3Nlyyx0TGOd7ZsqyVKX4elw9eg1fcARQA0Sm7Z6TukuZ7Fz7hHO/
oF8i0AH0karTMF4VtjWYnAuFMSfJoce4+CfQaBLSRRjMFNOXVA7C9EFDkijRLBtE
w3xhSqbrvHnMJZPaiyDXi2oAUKrC2v0qL611u5wthqHk+7kmzLCP3GMsF+Jd78xS
bFT7dsJF7SlGWik771gDRzSjXTBhspAj6+RXJGId8R8swShb/1c+SyzJglzZM5B5
NsmQSoffbUYnsRL9/8sowuvEKjj4nhkSd7f7/+fQOciJt3ytQiweKkvH+Nz3gEHx
Hem7Kl8xnfXWY0aNiwHFCppj4LwwCtZaBBnpTgGft6n6k8YQit5aU2Ig8s21tRHe
/xwl5Qegw1lAADJ4onkf3ezjoM2B2VaK+5mynifRlJ1+yno/eP8vxdNwwkg1RvcR
R3XYNAHl
=IskI
-----END PGP SIGNATURE-----

--8e86EYnzsf3lbPBd--