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