emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Davis Herring
Subject: Re: `*' interactive spec in some text-killing functions
Date: Thu, 28 Jun 2007 08:08:31 -0700 (PDT)
User-agent: SquirrelMail/1.4.8-6.el3.2lanl

>> 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. I want a warning (and please don't explain me
> again the differences between warnings and errors: 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).

A command failing to accomplish anything useful is not an error; a command
being impossible to execute is.  (I'm not harping on error/warning here,
just error/no-error.)  That's why `save-buffer' prints a message and
doesn't signal an error when the buffer is unmodified; saving is
_possible_ and _valid_, but useless (and so optimized out).  Similarly C-a
C-a does not even print a message the second time, though surely a user is
confused if they type that.  But since exactly what the user asked for has
happened, they aren't listening for a hard disk click or so, and no damage
has occurred or become likely, it's not even considered worthwhile to
print something.

The same sort of judgment call is needed for `overwrite-mode': however,
since it did do precisely what was asked, did have an effect, and still
poses no threat, it might actually be confusing to have it jabber about
its feelings of inadequacy.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]