Gnus development mailing list
 help / color / mirror / Atom feed
From: Russ Allbery <rra@stanford.edu>
To: ding@gnus.org
Subject: Re: message-confirm-send
Date: Thu, 15 Nov 2007 15:08:20 -0800	[thread overview]
Message-ID: <87zlxfhztn.fsf@windlord.stanford.edu> (raw)
In-Reply-To: <87bq9vazy8.fsf@jidanni.org> (jidanni@jidanni.org's message of "Fri, 16 Nov 2007 06:47:27 +0800")

jidanni@jidanni.org writes:

> Don't tell me all you manly man types run around all day without at
> least one of
> $ alias
> alias cp='cp -i'
> alias mv='mv -i'
> alias rm='rm -i'
> $ set -o
> noclobber       on

The most useful analysis I've read of this sort of UI feature is that the
usefulness of confirmation is inversely proportional to two things:

* The frequency of the action.  "Do you really want to delete your entire
  authentication database?" is a more useful question than "do you really
  want to list the contents of this directory?"

* The ability of the confirmation logic to recognize common cases and
  *not* ask for confirmation for them, only in cases that are unusual and
  for which there's some reason to be unsure.

The usefulness is *not* as clearly correlated with the severity of the
operation.  Frequency is far more important.  This is because confirmation
of frequent operations becomes automatic.  Adding confirmation before
sending a message will, for most people, essentially just change the
keystroke for sending a message from C-c C-c to C-c C-c y.  One becomes
trained to enter the whole sequence each time, and then one ends up
confirming even when one didn't want to.

I've seen this behavior all the time with things like rm -i.  People get
so used to always entering y that the confirmation is useless for
preventing mistakes.

So, to look at those aliases again and judge them against the above
criteria, I consider the rm -i alias to be useless.  It just prompts for
every file deletion and trains one to type y automatically.  On the other
hand, the cp -i alias and the noclobber setting I use personally, since
overwriting a file is *not* the common case for cp, or for redirects, and
while I become trained to enter y automatically after cp when I know I'm
overwriting a file, the confirmation successfully catches cases where I
didn't realize I was overwriting a file.

By that criteria, confirmation on C-c C-c, since it happens every time
without any recognition of common cases and attaches to a frequent
operation, is useless in much the same way that the rm -i alias is
useless.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



  parent reply	other threads:[~2007-11-15 23:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-14 18:58 message-confirm-send jidanni
2007-11-14 21:05 ` message-confirm-send Adam Sjøgren
2007-11-14 21:09   ` message-confirm-send Leo
2007-11-15 20:13     ` message-confirm-send jidanni
2007-11-15 20:29       ` message-confirm-send Bastien
2007-11-15 22:47         ` message-confirm-send jidanni
2007-11-15 22:55           ` message-confirm-send Karl Kleinpaste
2007-11-15 23:08           ` Russ Allbery [this message]
2007-11-15 23:38             ` message-confirm-send jidanni
2007-11-15 23:58             ` message-confirm-send Miles Bader
2007-11-16  0:20               ` message-confirm-send Russ Allbery
2007-11-17  2:37                 ` message-confirm-send Miles Bader
2007-11-17 10:23                   ` message-confirm-send Bastien
2007-12-06 12:48                     ` message-confirm-send jidanni
2007-12-06 18:31                       ` message-confirm-send Reiner Steib
2007-12-12 17:50                         ` message-confirm-send jidanni
2007-11-25  3:26               ` message-confirm-send Giorgos Keramidas
2007-12-18  5:24             ` shell-mode flakey [was Re: message-confirm-send] jidanni
     [not found]             ` <mailman.5147.1197955487.18990.bug-gnu-emacs@gnu.org>
2007-12-18 16:19               ` shell-mode flakey Roland Winkler
2007-12-19  0:31                 ` Miles Bader
2007-12-19  2:22                 ` Russ Allbery
     [not found]                 ` <mailman.5185.1198024311.18990.bug-gnu-emacs@gnu.org>
2007-12-19 16:25                   ` Sven Joachim
2007-11-17  9:23           ` message-confirm-send Reiner Steib
2007-11-25  3:20           ` message-confirm-send Giorgos Keramidas
2007-11-26 12:51             ` message-confirm-send jidanni
2007-11-21 16:31     ` message-confirm-send Ted Zlatanov
2007-11-14 21:18 ` message-confirm-send Bastien
2010-10-01 20:03 ` message-confirm-send Lars Magne Ingebrigtsen
2010-10-23  4:22   ` message-confirm-send jidanni
2010-10-23  9:17     ` message-confirm-send Alberto Luaces
2010-10-23 10:18       ` message-confirm-send Richard Riley
2010-10-23 13:55         ` message-confirm-send Bruno Tavernier
2010-10-24 14:46           ` message-confirm-send jidanni
2010-10-25 18:32             ` message-confirm-send Ted Zlatanov

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=87zlxfhztn.fsf@windlord.stanford.edu \
    --to=rra@stanford.edu \
    --cc=ding@gnus.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).