GNU bug report logs - #22819
25.0.91; Don't try to indent region if the buffer is read-only

Previous Next

Full log

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

From: John Wiegley <jwiegley <at> gmail.com>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 22819 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#22819: 25.0.91;
 Don't try to indent region if the buffer is read-only
Date: Tue, 08 Aug 2017 14:31:38 -0700

>>>>> "KM" == Kaushal Modi <kaushal.modi <at> gmail.com> writes:

KM> I don't know what the outcome should be in this case:
KM> - No one raised any issue moving forward with this in that emacs-devel.

Hello, Kaushal.

It should be pointed out here that maintenance of Emacs is at the maintainers'
discretion. Even though we do take the opinions of others into account, just
because emacs-devel "hasn't raised an issue", does not mean that a change will
happen. If Eli and I don't like it, the issue must wait for the next round of
maintainers.

There are a few factors why this change is being rejected now:

  a. It is a long-standing behavior, however less than ideal it is. We don't
     know what effect changing it will have, as obvious as it may seem. Our
     strongly-held policy is to avoid changes in long-standing behavior unless
     the reason to do so is compelling.

  b. The main force of your argument is that we waste CPU time when we don't
     need to, because we could just check before doing the indentation. I have
     no argument with that, and you're quite right. However, in all my years
     of using Emacs I've never run into this case, so I don't buy the argument
     that it is a change that needs to happen right now, for everyone.

  c. Emacs is designed to be extensible. Advise the indentation functions so
     they perform this check for you. It doesn't need to happen in core Emacs
     for you to get the behavior you want.

If your wish is to defend the interests of the "silent majority", who all,
without knowing it, would benefit from this change, then I appreciate your
concern. However, as maintainers, and given the lack of other voices *asking*
for this change, we prefer to retain the status quo, however far from perfect
it may be.

Plenty of projects on the Net strive to make every breaking change necessary
to approximate the best version of what they're trying to accomplish. That's
not how it is here. We want a stable, well-functioning Emacs with predictable
behavior, and sometimes that means keeping things as they have been for
decades -- even if, in hindsight, it shouldn't have been done that way.

What I'm interested to learn is how many other cases like this exist, and
whether a more general approach would make it less likely for it to occur.
What if we could know, for example, whether a function will try to change the
buffer, and simply stop the evaluation before it starts...

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Previous Next

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