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

[John Wiegley]

>>>>> 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

signature.asc
Description: PGP signature