On Sat, Aug 5, 2017, 8:10 AM Eli Zaretskii <eliz@gnu.org> wrote:

>
> I see no problem in it, sorry.  And why was the user not aware of the
> read-only status of the buffer to begin with?


Cockpit error, as you say later. It's easy to forget if you are working on
a DVCS (like git) controlled file or CVCS (like SOS).

 How

plausible is such a
> scenario?


I resorted to writing this patch because it frustrated me quite a few
times.

 Are

we trying to change Emacs behavior to cater to a clear
> cockpit error?
>

Isn't it better to alert user of an operation that will not succeed anyways
beforehand, especially if the operation can be expensive like this one?

> >against veteran Emacs behavior regarding read->only text,
> > >behavior that is present in several other >commands, and that AFAIR
> > >resulted from some past discussions.
> >
> > This is the only one that provided me this surprise in about a decade of
> Emacs use. Which other commands
> > do the text manipulation, and then check the buffer read-only status?
>
> C-w, to name just one.
>

OK, it would be unnoticeable in that case as I have yet to see a kill
operation that can take couple of minutes.

IOW, a command could have useful side effects that are produced even
> if the buffer is read-only and its text cannot be changed, thus
> preventing the main effect of the command from happening.
>
> > The flip question is: How common is a workflow, where a buffer is
> read-only, user does indentation, and is fine
> > with seeing that error after the fact?
>
> This goes both ways: if it's uncommon enough to be unimportant, then
> changing the behavior is not important as well.
>

Would it be OK to open this up to emacs-devel to understand what workflows
can break because of this change?

> --

Kaushal Modi