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 #22 received at 22819 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22819 <at> debbugs.gnu.org, Noam Postavsky <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 12:29:15 +0000

[Message part 1 (text/plain, inline)]

On Sat, Aug 5, 2017, 8:10 AM Eli Zaretskii <eliz <at> 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

[Message part 2 (text/html, inline)]

Previous Next

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