From: John Wiegley <jwiegley@gmail.com>
To: Kaushal Modi <kaushal.modi@gmail.com>
Cc: 22819@debbugs.gnu.org, npostavs@users.sourceforge.net
Subject: 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 [thread overview]
Message-ID: <m2o9rpd9vp.fsf@newartisans.com> (raw)
In-Reply-To: <CAFyQvY0yJMGL=isZxXhHVRBDH-_jMDHvoa+UMgEVaf-H4ETrLQ@mail.gmail.com> (Kaushal Modi's message of "Tue, 08 Aug 2017 19:19:31 +0000")
>>>>> "KM" == Kaushal Modi <kaushal.modi@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
next prev parent reply other threads:[~2017-08-08 21:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 13:54 bug#22819: 25.0.91; Don't try to indent region if the buffer is read-only Kaushal Modi
2017-08-05 1:56 ` npostavs
2017-08-05 6:52 ` Eli Zaretskii
2017-08-05 11:50 ` Kaushal Modi
2017-08-05 12:10 ` Eli Zaretskii
2017-08-05 12:29 ` Kaushal Modi
2017-08-05 12:37 ` Eli Zaretskii
2017-08-05 12:47 ` npostavs
2017-08-05 13:13 ` Eli Zaretskii
2017-08-07 17:45 ` Kaushal Modi
2017-08-07 17:53 ` Noam Postavsky
2017-08-07 18:02 ` Kaushal Modi
2017-08-07 18:11 ` Noam Postavsky
2017-08-08 13:06 ` Kaushal Modi
2017-08-08 13:15 ` npostavs
2017-08-08 19:05 ` Eli Zaretskii
2017-08-08 19:19 ` Kaushal Modi
2017-08-08 21:31 ` John Wiegley [this message]
2017-08-09 11:03 ` Kaushal Modi
2017-08-09 21:14 ` John Wiegley
2019-06-25 14:33 ` Lars Ingebrigtsen
2019-06-25 14:35 ` Kaushal Modi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2o9rpd9vp.fsf@newartisans.com \
--to=jwiegley@gmail.com \
--cc=22819@debbugs.gnu.org \
--cc=kaushal.modi@gmail.com \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.