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

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Sat, 05 Aug 2017 11:50:59 +0000
> Cc: 22819@debbugs.gnu.org
> 
> 1. User: Try indentation
> 2. User: Could take several seconds or few minutes (depending on major mode 
> and file size)
> 3. Emacs: "Bummer, couldn't save all that indentation because the buffer is 
> read-only".
> 4. User: Make buffer editable. It's not a simple act of chmod. In my case, 
> the buffer was read-only because the
> file is part of a centralized version control system (Cliosoft SOS). In 
> "checked in" state, the file is just a
> symlink to the cached version in server, and thus read-only. To make it 
> editable, I need to "check out" the file.
> That act replaces the symlink link with a physical file copy. 
> 5. User: Re-do that several seconds/minutes long indentation.
> 
> My commit saves the user from wasting that time in Step 2 above. 
> 
>  The original submission provided no rationale for the change, so it's
>  hard to reason about its advantages.
> 
> Please consider the above use case. 

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?  How plausible is such a
scenario?  Are we trying to change Emacs behavior to cater to a clear
cockpit error?

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

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.