all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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

  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.