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

[Juanma Barranquero]

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

> A warning causes an action to continue (and usually no beep), an error
> aborts the current operation (including a keyboard macro) and beeps.

I *know*. When I said "a warning" I added "IMHO". I wasn't (am not)
talking in general, but about overwrite-mode. Or do you mean that it
would be very different

(defun overwrite-mode (&optional arg)
  (interactive "*P")
  ...

from

(defun overwrite-mode (&optional arg)
  (interactive "P")
  (when buffer-read-only
     (message "Arggg!"))
  ...)

*other* than the fact that the second one really changes the mode
(which is not very important for the issue I'm discussing).

> Well, that's only fair.

It was a literal truth. I didn't understand what you were trying to
say. My fault.

> On my side, I have no clue whatsoever what
> you are trying to achieve with your proposal that one should not be
> able to change between overwrite and insertion mode in a readonly
> buffer.

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.

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

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

            Juanma