Re: `*' interactive spec in some text-killing functions

[David Kastrup]

"Juanma Barranquero" <address@hidden> writes:

> On 6/28/07, David Kastrup <address@hidden> wrote:

[...]

> I don't remember proposing that. Honestly, what I'm saying wouldn't
> be very affected by using the second alternative above (the
> message/warning one) instead of the error one. I'm not talking about
> interrupting the change (that's irrelevant), but warning the user of
> a likely error.

What error?  The problem is an attempt to _change_ the buffer.
Changing something like overwrite-mode does not change the sets of
legitimate and refused operations.

>> For example, I find it completely legitimate to change to overwrite
>> mode, then lock out a file from RCS (which makes it writable), work
>> on it, check it in and then change back from overwrite mode (even
>> though the buffer is already again readonly).
>
> That's an specific example. Good. Are there many more situations in
> which switching to overwrite in a read-only buffer is meaningful and
> more-or-less frequent?

Can you name a single situation where the user gets _any_ benefits
from balking at toggling overwrite-mode?  It is not like work is
getting lost or something.

>> I see no point whatsoever to throw an error in that situation.
>
> Fine. Would you feel different if I proposed adding
>
> (when buffer-read-only
>    (message "Warning: buffer is read-only"))
>
> at the top of overwrite-mode?

Why would you want to do that?  In what situation would the user
derive any benefit from that?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum