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

Previous Next

Full log

Message #19 received at 22819 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 22819 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#22819: 25.0.91;
 Don't try to indent region if the buffer is read-only
Date: Sat, 05 Aug 2017 15:10:22 +0300

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Sat, 05 Aug 2017 11:50:59 +0000
> Cc: 22819 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.