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

[David Kastrup]

"Juanma Barranquero" <address@hidden> writes:

> On 6/28/07, David Kastrup <address@hidden> wrote:
>
>> WHY?!?!?  WHY would it be convenient?  PLEASE, PLEASE, PLEASE, explain
>> in what respect it would help you at all save time, confusion or
>> whatever.  _Why_ can't you explain what gains you would draw from such
>> a message?
>
> David, I explained many messages ago, and you're refusing to listen:
> If I do a command, and the result of this command is irrelevant, I
> consider it an error.

But the result of the command is _not_ irrelevant since the buffer
need not remain read-only.

Should we get an error for C-s RET as well since the cursor has not
moved?  Or whenever if we copy something into the kill ring?

"Warning: the copy into the kill ring will remain irrelevant unless
you yank it elsewhere".

> I want a warning (and please don't explain me again the differences
> between warnings and errors:

Then why do you come up with the PgUp example all the time which is an
_error_, not a warning?  It throws a signal which will abort the
current operation _unless_ there is a signal handler for it.  Even
then, the command will not complete but rather execute the signal
handler.

windows.c:5145:

      else
        {
          if (w->vscroll != 0)
            /* The first line was only partially visible, make it fully
               visible. */
            w->vscroll = 0;
          else if (noerror)
            return;
          else
            xsignal0 (Qbeginning_of_buffer);
        }

> I understood it already the first time I used "warning", but I
> didn't have the insight to be very precise in my use of Emacs
> terminology because I didn't imagine that would turn into that kind
> of discussion).

So could you come up with an example with similar behavior that gives
a _warning_, not an _error_, and which _completes_ the operation?

> You're arguing that is not irrelevant because the mode gets changed
> and, in some situations, it is even useful. I don't have *any*
> useful day to day activity with Emacs where switching to overwrite
> in a read-only buffer is useful, so *I* want to get a message
> telling me that I'm doing something superfluous.

Something _prospectively_ superfluous in _certain_ situations.  So
please, please, please, give one usage case where such a warning would
save you time, data loss, or anything else that would even offset the
inconvenience of having the *Message* buffer filling with warnings
because I fell asleep on the "Insert" key.

I don't have any situation where
(setq fdsajglghragh t)
would be useful, and I don't want a message telling me.

> You're arguing that the PgUp command case is different (and yes, I
> understand quite well how it works, thanks), but it is *not*: PgUp
> could refuse to work without alerting the user, and nothing would be
> different *at all*,

But Emacs does _not_ refuse to toggle overwrite mode.  Take a look at
the mode line: it toggles it quite fine.  No warning necessary.  It
will not accept buffer modifications in either state, yielding an
error in either state.

> except that the user would take a few seconds to notice what was he
> doing wrong. The message in the PgUp case is *just* *to* *say* *the*
> *user* *he's* *doing* *something* *not* *useful*.

Not useful _yet_.  And it does not cause the user to invest any amount
of time and work that would go to waste.

"Warning: you changed overwrite-mode, and this might mean you want to
change the buffer at some point of time.  When you will try doing
that, it will not work."

This is complete nonsense: we can give an _error_ if and when the user
changes the buffer, and we could give that warning at almost any point
of time.  "Warning: you pressed C-u.  If you now press a
self-inserting character, I still won't change the buffer."

A warning is only useful if there are _consequences_ for not heeding
the warning.  But there _aren't_ in this case.

-- 
David Kastrup