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

Previous Next

Full log

Message #401 received at 78474 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sébastien Hinderer <Sebastien.Hinderer <at> inria.fr>
Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com,
 samuel.thibault <at> gnu.org
Subject: Re: bug#78474: 31.0.50; Wrong char insertion in rxvt
Date: Wed, 23 Jul 2025 15:22:12 +0300

> Date: Wed, 23 Jul 2025 09:52:10 +0200
> From: Sébastien Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, bzg <at> gnu.org,
> 	78474 <at> debbugs.gnu.org
> 
> A very friendly note to the Emacs maintainers whoare reading this
> thread: my intention is *not* tomake you feel bad. I appreciate that you
> are here, discuss, genuinely try tounderstand. Precisely, to broaden
> your understanding, I would like to explain one point you may be missing
> and it's certainly not your faul if you are missing it, but please read
> me and think over it.
> 
> The discussion we are currently having with you, wehave to  haveon
> dozens and dozens of projects. So yes, having to have such discussions
> again and again is super tiring and it's kind of a miracle that people
> like Samuel are still there, although not directly concerned.
> 
> We try to suggest solutions that are viable, as "main stream" as
> possible because we believe that the best thing that can happen to
> accessibility is that it gets integrated to programs as readily as
> possible.
> 
> As much as possible, we would like to avoid that accessibility has to go
> to dedicated code paths because we know from experience tat, in the long
> run, such code paths will receive less testing and maintenance
> attenition.
> 
> And I think this becomes even more true if, as it seems to be the case
> here, the proposed code is actually cleaner, more efficient and more
> standard than what was done before. Tome, the fact that the former code
> has not had to change for decades does not mean it shouldn't be changed
> now.

Your point is well taken!

However, please also see this and other similar issues from our POV.
Emacs users are a legion, and they use Emacs in many different usage
patterns and on many different platforms.  We cannot risk making
changes that might adversely affect some group of users, because some
other group of users wants the change and considers it important, or
even if we ourselves consider the change important.  The reason is
simple: the people who want the change will go away satisfied, but the
others will come to us complaining, and we will face the same problem
once again.

Emacs users trust us not to break or adversely affect functionality
that existed for decades.  We try very hard not to betray that trust.

That is why we must carefully examine the effects of the proposed
changes, to make sure we understand them and to avoid causing
regressions in some cases, and we must explore all the possible
solutions that could give each one what they want without adversely
affecting the others.  And that is what I'm trying to do.  So please
bear with me and help me understand both the problem and its causes,
and the effect of each proposed solution, so that the decision will
not be just moving the problem from one group of users to another.

Thanks.

Previous Next

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