all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.