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

--boda6X7I5RwSLr45
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jul 27, 2026 at 09:46:31PM +0200, Steffen Nurpmeso wrote:
> Crystal Kolipe via Mutt-dev wrote in
>  <[email protected]>:
>  |On Sat, Jul 25, 2026 at 09:01:36PM +0800, Kevin J. McCarthy wrote:
>  |> But my understanding was that general expectations have changed.  vim=
 and
>  |> emacs (without a configuration file) delete forwards, as does bash. At
>  |> least, for me they behave that way.
>  |
>  |The logic for 'delete' deleting forwards becomes clearer if you think \
>  |of it as
>  |the opposite of 'insert' on a terminal with auto-insertion disabled,
>  |(I.E. overtype mode).
>  |
>  |In that case, it's usually expected that hitting 'insert' immediately \
>  |followed
>  |by 'delete' would be a no-op.  In other words, the 'delete' would remov=
e \
>  |the
>  |blank space inserted.
>=20
> I would maybe ask Thomas Dickey who magically appears on
> uncountable lists when any of termcap or terminfo (or xterm)
> problems are about to be addressed, maybe also this time.

maybe.

X/Open doesn't actually spell it out, saying what dch1 does.
Instead, we have this:

	Whenever possible, capability names are chosen to be the same
	as or similar to those specified by ISO/IEC 6429:1992.
	Semantics are also intended to match those of that standard.

So... for dch1 (and dch), we refer to ECMA-48 (same text) to get the
description of DCH (just quoting the most relevant part):

	If the DEVICE COMPONENT SELECT MODE (DCSM) is set to PRESENTATION, DCH
	causes the contents of the active presentation position and, depending
	on the setting of the CHARACTER EDITING MODE (HEM), the contents of the
	n-1 preceding or following character positions to be removed from the
	presentation component, where n equals the value of Pn.  The resulting
	gap is closed by shifting the contents of the adjacent character
	positions towards the active presentation position.  At the other end
	of the shifted part, n character positions are put into the erased
	state.
=20
HEM is basically a mode for right-to-left vs left-to-right, so that reduces
to saying what we expect: DCH deletes in the "forward" direction by shifting
the rest of the line left by n cells, leaving the ones on the right end as
"erased".

However, all of the fuss has been about kdch1, which is outside the scope
of ECMA-48.  While ECMA has a standard for keyboard layout, there's no
standard for what special keys send.  There's a convention (providing
special keys which send escape sequences like the similarly-named
capabilities), but it's far from 100% in the terminal database:

	About half of the terminal descriptions have a kdch1.

	About a third of those have dch1 =3D=3D kdch1.  In the other 2/3,
	some of those kdch1's are DEL (i.e., ^?), but there are in a quick
	count 24 different codes used in kdch1's.

The convention is more common with cursor-keys (about 70% for cursor
left and right).

> If for one am all in the delete-forward camp, and have for example
> for decades in my ~/.inputrc
>=20
>   $if term=3Dcons25
>   ...
>   $if term=3Drxvt
>=20
> and some more, and all have delete-char entries.  And to say that
> the OpenGroup has standardized termcap/terminfo, and in 1997 (i do
> not really know what i talk about) "kdch1" was delete-character,
> and delch(3) deletes a character (forward) without moving the
> cursor.
>=20
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>=20

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

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

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

iQGzBAABCgAdFiEEGYgtkt2kxADCLA1WzCr0RyFnvgMFAmpn+1MACgkQzCr0RyFn
vgNJ9gv7BzqKb/HZDiPjJUIXupJ24ddmJaw0kq2HJK3sdPCOrixMdtpo3oFJ2egi
r8xSJnvdOqljGMN0Dke5g02TIouz8MRVmFTfePExxkKDhE5hkKx9ZgIQ9jXfTIqb
GhN1mk9ZZ05jx5B340q5DGE7f7EzAdzDrWExT6eqqJJ4Wv8MJtqsWzQJgTf1JYbS
HqOpBWEq/fFleaU9H3B2SLgbEJC7XgUbeBpa0UdSsriV6N55bxrHIWBxhKCL/Phr
LB1pjEIB8cfCpa1GuvTZK6s8G49EI5RtJA+HbmCMKg6F/VmgyQqLUTDLR7rIwDCQ
3TYtPGMunvoUR97rY+WTbB5ggCqw7l0UOgTxvN1OI84CkDNgxQ02MGtEdotQ0zAA
USg302ddDZH/aGct81Z/9x65xtdaXfC5FU44MafgyUn1HIkscNnWg4doZJ3QQ6D6
/zr5p1oYXSkFXCnT1ELSTo/iLu49EBwIVWz6Z12axGzrgggQEi4irnDrwkkfFV+a
H3RopYjK
=PS9t
-----END PGP SIGNATURE-----

--boda6X7I5RwSLr45--