> - Are there any objections to doing the buffer read-only check before
> doing the indent?
Dunno what the right approach/solution is in this particular case.
But note that we don't do what you suggest in general - we don't do it
for most other editing operations: insert or delete a character, yank
a string, kill the region,... Instead, we let an error be raised,
telling the user that the buffer is read-only.
This case feels a bit different because the operation can be very expensive.. a few seconds or couple of minutes long indentation, based on the major mode and file size. So a user would find it tremendously helpful to know that the operation is useless on a read-only buffer before spending that amount of time.
With the cases of insert/delete char, yank string, kill region, I have never noticed any tangible delay (read: even a second).. so in those, it do not matter if you "do and then flag error" or "flag an error and then do".
Also there are many cases of commands meant for buffer editing (like keep-lines, flush-lines, etc.) where barf-if-buffer-read-only is used for the same purpose.
The purpose of this email thread is to understand if there's a workflow someone uses that would break if this read-only check were done at the beginning of the indentation operation. As Eli states his concern in the Bug#22819, do people rely on side-effects other than the actual buffer-editing indentation operation?