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