GNU bug report logs - #78474
31.0.50; Wrong char insertion in rxvt

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Samuel Thibault <samuel.thibault <at> gnu.org>
Cc: bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, 78474 <at> debbugs.gnu.org
Subject: bug#78474: 31.0.50; Wrong char insertion in rxvt
Date: Tue, 22 Jul 2025 16:42:29 +0300

> Date: Tue, 22 Jul 2025 14:27:30 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 	78474 <at> debbugs.gnu.org
> 
> Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> > And not a solution that will break as soon as somebody creates their
> > own screen reader for their own use.
> 
> To put some context here: one of the latest screen readers out there,
> odilia, is already concerned by the amount of existing workarounds
> for accessibility in general. If they bang their head against walls
> concerning \t\b, wondering why that works with the well-known orca
> screen reader, and not with their own, and end up seeing a hardcoded
> list of the screen readers that are fortunate enough to be known enough
> to get the proper behavior of emacs in vte, as opposed to the screen
> reader that they are trying to write, then yes, I believe they could
> almost litteraly throw up.

Emacs makes it very easy to modify such databases.  Saying the names
of such programs are "hardcoded" is not really accurate for Emacs,
because we can expose the list as a user option, so users could easily
add/remove programs as needed.

Again, I'm not saying this must be the solution, but it could be, from
where I stand.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.