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

[Kaushal Modi]

On Tue, Aug 8, 2017, 5:31 PM John Wiegley <jwiegley@gmail.com> wrote:

Hello, Kaushal.

Hi John, thanks for your input. 

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.

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

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.

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.

  b. The main force of your argument is that we waste CPU time when

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

 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.

This change can be truly tested and appreciated only by people dealing with read-only files everyday. This would be mostly people working with a central version control system that makes all the files yet to be checked-out as read-only symbolic links. I deal with dozens of read-only files everyday, with a mix of editable files that are managed by git. So I am likely to do the mistake of indenting a read-only file (i.e. indenting a CVCS file before checking it out). Again, the benefit of this change is not seen unless the indentation operation takes at least a few seconds (depends on file size and major mode).

 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.

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

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.

I doubt that will ever change because my situation as I explained above, of working with primarily read-only files is not in majority. 

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.

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. 

 That's

not how it is here. We want a stable, well-functioning Emacs with predictable
behavior,

*predictable*: What should one expect to happen if one tried to indent-region in a read-only file? Would one be surprised if a read-only error is thrown? Emacs already does that.. just that this proposal does just that *before* the time-consuming indentation attempt is started. 

So this patch should bring no noticeable change to a majority of people. But people in minority like me -- (i) like to obsessively keep all files well-indented (ii) working with read-only files (iii) time-consuming indentation (major mode and file size dependent) -- would heavily appreciate this. 

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,

I doubt if many still exist because the ones that affected most people are already fixed by using the same approach (as in this proposal) of using * interactive form or barf-if-buffer-read-only. 

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

This prolonged discussion makes me think "What's the point?". I can barely convince to commit this 1-line change to the master branch that can be easily reverted even if a single person complained. 

--

Kaushal Modi