From: David Kastrup <dak@gnu.org>
To: "Juanma Barranquero" <lekktu@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: `*' interactive spec in some text-killing functions
Date: Thu, 28 Jun 2007 11:04:26 +0200 [thread overview]
Message-ID: <86d4zgxxet.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <f7ccd24b0706280141k11591ddck7d4ecbc879e20ed0@mail.gmail.com> (Juanma Barranquero's message of "Thu\, 28 Jun 2007 10\:41\:33 +0200")
"Juanma Barranquero" <lekktu@gmail.com> writes:
> On 6/28/07, David Kastrup <dak@gnu.org> 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
next prev parent reply other threads:[~2007-06-28 9:04 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-27 13:39 `*' interactive spec in some text-killing functions Juanma Barranquero
2007-06-27 14:08 ` David Kastrup
2007-06-27 14:25 ` Juanma Barranquero
2007-06-27 14:55 ` David Kastrup
2007-06-27 15:52 ` Juanma Barranquero
2007-06-27 16:22 ` Andreas Schwab
2007-06-27 18:43 ` Juanma Barranquero
2007-06-27 20:59 ` David Kastrup
2007-06-27 21:30 ` Juanma Barranquero
2007-06-27 22:04 ` David Kastrup
2007-06-27 22:11 ` Juanma Barranquero
2007-06-27 22:24 ` David Kastrup
2007-06-27 22:43 ` Juanma Barranquero
2007-06-27 23:13 ` David Kastrup
2007-06-27 23:22 ` Juanma Barranquero
2007-06-28 5:23 ` David Kastrup
2007-06-28 7:51 ` Juanma Barranquero
2007-06-28 8:07 ` David Kastrup
2007-06-28 8:15 ` Juanma Barranquero
2007-06-28 8:25 ` David Kastrup
2007-06-28 8:41 ` Juanma Barranquero
2007-06-28 9:04 ` David Kastrup [this message]
2007-06-28 9:09 ` Juanma Barranquero
2007-06-28 9:16 ` David Kastrup
2007-06-28 9:22 ` Juanma Barranquero
2007-06-28 9:48 ` Andreas Schwab
2007-06-28 10:21 ` Juanma Barranquero
2007-06-28 11:14 ` Andreas Schwab
2007-06-28 11:33 ` Juanma Barranquero
2007-06-28 10:55 ` David Kastrup
2007-06-28 14:03 ` Stefan Monnier
2007-06-28 14:12 ` David Kastrup
2007-06-28 14:16 ` Juanma Barranquero
2007-06-28 14:30 ` David Kastrup
2007-06-28 14:39 ` Vinicius Jose Latorre
2007-06-28 14:51 ` David Kastrup
2007-06-28 15:21 ` Luc Teirlinck
2007-06-28 15:38 ` Juanma Barranquero
2007-06-28 22:07 ` Mathias Dahl
2007-06-28 22:20 ` David Kastrup
2007-06-28 22:31 ` Juanma Barranquero
2007-06-28 16:25 ` Robert J. Chassell
2007-06-28 15:08 ` Davis Herring
2007-06-28 15:22 ` Juanma Barranquero
2007-06-28 8:47 ` Lennart Borgman (gmail)
2007-06-28 9:11 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86d4zgxxet.fsf@lola.quinscape.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.