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: Wed, 09 Aug 2017 14:14:45 -0700	[thread overview]
Message-ID: <m2valwphpz.fsf@newartisans.com> (raw)
In-Reply-To: <CAFyQvY1zCVcFD-VhxLm9K7nSNQ8D7DOwbk71_5vms5NFO9o8Mw@mail.gmail.com> (Kaushal Modi's message of "Wed, 09 Aug 2017 11:03:34 +0000")

[-- Attachment #1: Type: text/plain, Size: 3511 bytes --]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> Understood. My only hope that I can convince the maintainers with my reason
> that this proposal fixes a real-life problem with the help democratic voting
> system (if the opinions asked on emacs-devel matter and can be called that).

That's fair, though we still need to be personally convinced. :) Ancient
behavior has a mystique that requires a fair bit of motivation for us to
change. It really just comes down to the fact that Eli and I are conservative
fellows in these things.

> Wouldn't the master branch be a good playground for this? If it affects
> people negatively, it's just a one-line commit and thus easy to revert.

I'm not sure enough people use the master branch for it to determine how it
will affect the majority.

In all likelihood it won't affect anyone badly at all (I don't really see how
it could), it's just not something we need to do today. I'm fine with keeping
the issue open, though. My preference would be that another solution will
solve this, and all similar issues, by way of a better design. Otherwise,
we're picking at gnats in a sensitive area (i.e., long-held behavior).

> I should have used the term "wall time". This issue has wasted quite a few
> minutes for me.

Understood.

> Of course. I will do that. I was just hoping the "right fix" would get in.
> (Otherwise why would anyone bother to submit bug reports and patches?)

You're making us aware of bad implementation decisions made long ago, which
are good to know about. There have been other, fairly long, debates on the
meaning of the "read-only" bit, and when a buffer should get marked as
modified. I'm sure these issues relate to yours as well. For example: should a
buffer-modifying operation be aborted early even if the actual operation of
the function won't change anything? People argue that M-q shouldn't mark a
buffer as modified if the reformatting changes nothing: does that mean M-q
should be allowed on a read-only buffer if it doesn't modify, or should it
abort early because its makes no sense?

And how many people have built up macros or customizations or custom functions
in their configuration that rely on ultimately-non-modifying operations being
allowed in read-only buffers, rather than turning them into errors? Arguably
their code is "wrong", but how much of their time should we waste by fixing
this and causing their keyboard macros to break?

I realize my argument tends toward "change nothing", but that's not what I
mean. I'm only saying that there's a lot of users to be considered, so unless
we *need* to risk breakage, we prefer to avoid it. The current behavior has
been around for a long, long time, and while it's painful for your use case, I
know you have the expertise to advise Emacs as needed.

> I haven't yet got an answer to a real-life scenario that would break by this
> change. What kind of (i) side-effects would one be relying on (ii) while
> running indent-region (iii) on read-only files?
> 
> It's a bit sad, I am presenting a solution to a real problem and the counter
> argument is just one, and hypothetical.

We don't normally have any counter-evidence that an old, bad behavior *should*
be kept. It's more an argument that we don't change them until we're convinced
it's time.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]

  reply	other threads:[~2017-08-09 21:14 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
2017-08-09 11:03                       ` Kaushal Modi
2017-08-09 21:14                         ` John Wiegley [this message]
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=m2valwphpz.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.