* Re: message-confirm-send
2007-11-15 22:47 ` message-confirm-send jidanni
@ 2007-11-15 22:55 ` Karl Kleinpaste
2007-11-15 23:08 ` message-confirm-send Russ Allbery
` (2 subsequent siblings)
3 siblings, 0 replies; 34+ messages in thread
From: Karl Kleinpaste @ 2007-11-15 22:55 UTC (permalink / raw)
To: ding
jidanni@jidanni.org writes:
> Don't tell me all you manly man types run around all day without at
> least one of
In fact, when setting up a new system, those aliases and settings are
among the first things I remove. They are an annoyance and hindrance.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
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
2007-11-15 23:38 ` message-confirm-send jidanni
` (3 more replies)
2007-11-17 9:23 ` message-confirm-send Reiner Steib
2007-11-25 3:20 ` message-confirm-send Giorgos Keramidas
3 siblings, 4 replies; 34+ messages in thread
From: Russ Allbery @ 2007-11-15 23:08 UTC (permalink / raw)
To: ding
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/>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 23:08 ` message-confirm-send Russ Allbery
@ 2007-11-15 23:38 ` jidanni
2007-11-15 23:58 ` message-confirm-send Miles Bader
` (2 subsequent siblings)
3 siblings, 0 replies; 34+ messages in thread
From: jidanni @ 2007-11-15 23:38 UTC (permalink / raw)
To: ding
Real manly types just hold C-c down until two are sent (and release
just before a third, which of course they have aliased to rm -r).
Anyway glad you guys' fingers are still so nimble. Pass the Geritol.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 23:08 ` message-confirm-send Russ Allbery
2007-11-15 23:38 ` message-confirm-send jidanni
@ 2007-11-15 23:58 ` Miles Bader
2007-11-16 0:20 ` message-confirm-send Russ Allbery
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>
3 siblings, 2 replies; 34+ messages in thread
From: Miles Bader @ 2007-11-15 23:58 UTC (permalink / raw)
To: Russ Allbery; +Cc: ding
Russ Allbery <rra@stanford.edu> writes:
> 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.
Perhaps a more useful solution to the "realize your mistake as soon as
you hit send" problem (and this at least, is real) would be undoable
mail. Undoability often seems like a better method than confirmation.
Since you can't actually undo mail sending, a more practical solution
then would be a default queuing period for outgoing mail and easy-to-use
tools to examine the queue and cancel pending messages.
I suppose it's all a bit too much effort (needs MTA cooperation etc) for
the gain though. [and would probably cause tons of complaints about
your "slow" mail system...]
-Miles
--
`The suburb is an obsolete and contradictory form of human settlement'
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 23:58 ` message-confirm-send Miles Bader
@ 2007-11-16 0:20 ` Russ Allbery
2007-11-17 2:37 ` message-confirm-send Miles Bader
2007-11-25 3:26 ` message-confirm-send Giorgos Keramidas
1 sibling, 1 reply; 34+ messages in thread
From: Russ Allbery @ 2007-11-16 0:20 UTC (permalink / raw)
To: ding
Miles Bader <miles@gnu.org> writes:
> Perhaps a more useful solution to the "realize your mistake as soon as
> you hit send" problem (and this at least, is real) would be undoable
> mail. Undoability often seems like a better method than confirmation.
> Since you can't actually undo mail sending, a more practical solution
> then would be a default queuing period for outgoing mail and easy-to-use
> tools to examine the queue and cancel pending messages.
> I suppose it's all a bit too much effort (needs MTA cooperation etc) for
> the gain though. [and would probably cause tons of complaints about
> your "slow" mail system...]
Gnus could probably implement something like this internally, though,
using a concept similar to the drafts group.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-16 0:20 ` message-confirm-send Russ Allbery
@ 2007-11-17 2:37 ` Miles Bader
2007-11-17 10:23 ` message-confirm-send Bastien
0 siblings, 1 reply; 34+ messages in thread
From: Miles Bader @ 2007-11-17 2:37 UTC (permalink / raw)
To: Russ Allbery; +Cc: ding
Russ Allbery <rra@stanford.edu> writes:
>> I suppose it's all a bit too much effort (needs MTA cooperation etc) for
>> the gain though. [and would probably cause tons of complaints about
>> your "slow" mail system...]
>
> Gnus could probably implement something like this internally, though,
> using a concept similar to the drafts group.
The problem would seem to be reliability -- once they've hit send,
people really, _really_, don't want email to be lost or even delayed for
longer than expected (e.g. a "undoable delay" of 5 minutes might be
acceptable, but 2 days almost certainly isn't).
MTAs in general have put huge amounts of effort into making mail queuing
fairly reliable, but I think any Gnus specific solution is bound to be
less so (and it's probably a lot of work to make it reliable).
-Miles
--
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-17 2:37 ` message-confirm-send Miles Bader
@ 2007-11-17 10:23 ` Bastien
2007-12-06 12:48 ` message-confirm-send jidanni
0 siblings, 1 reply; 34+ messages in thread
From: Bastien @ 2007-11-17 10:23 UTC (permalink / raw)
To: ding
Miles Bader <miles@gnu.org> writes:
> Russ Allbery <rra@stanford.edu> writes:
>>> I suppose it's all a bit too much effort (needs MTA cooperation etc) for
>>> the gain though. [and would probably cause tons of complaints about
>>> your "slow" mail system...]
>>
>> Gnus could probably implement something like this internally, though,
>> using a concept similar to the drafts group.
>
> The problem would seem to be reliability -- once they've hit send,
> people really, _really_, don't want email to be lost or even delayed for
> longer than expected (e.g. a "undoable delay" of 5 minutes might be
> acceptable, but 2 days almost certainly isn't).
I think some internal Gnus way of undoing mails would be a mistake. If
someone finds C-c C-c to be too dangerous, he might also use a different
key (provided he's aware that he will get used to this new key soon.)
> MTAs in general have put huge amounts of effort into making mail queuing
> fairly reliable, but I think any Gnus specific solution is bound to be
> less so (and it's probably a lot of work to make it reliable).
I tend to use C-c C-d more and more myself. Not only when I'm offline,
but also when I plan to quickly review the mail I send.
--
Bastien
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 23:58 ` message-confirm-send Miles Bader
2007-11-16 0:20 ` message-confirm-send Russ Allbery
@ 2007-11-25 3:26 ` Giorgos Keramidas
1 sibling, 0 replies; 34+ messages in thread
From: Giorgos Keramidas @ 2007-11-25 3:26 UTC (permalink / raw)
To: Miles Bader; +Cc: Russ Allbery, ding
On 2007-11-16 08:58, Miles Bader <miles@gnu.org> wrote:
>Russ Allbery <rra@stanford.edu> writes:
>> 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.
>
> Perhaps a more useful solution to the "realize your mistake as soon as
> you hit send" problem (and this at least, is real) would be undoable
> mail. Undoability often seems like a better method than confirmation.
>
> Since you can't actually undo mail sending, a more practical solution
> then would be a default queuing period for outgoing mail and easy-to-use
> tools to examine the queue and cancel pending messages.
>
> I suppose it's all a bit too much effort (needs MTA cooperation etc) for
> the gain though. [and would probably cause tons of complaints about
> your "slow" mail system...]
That's a very good suggestion, I think.
I am not worried too much about hitting `C-c C-c' too fast, because most
of the time I spent in Gnus is in agentized sessions. This means that
all outgoing Usenet posts and mail messages are queued by default, and I
can expire them from the `queue' group to undo the posting operation.
It doesn't happen very often that I want to expire a posted message, but
there have been at least 3-4 times the last year. This means that it is
far from a very common thing to do, but still not something useless or
completely unworthy of consideration.
Maybe an agentized session is something which the original poster may
consider as an `improved mode of using Gnus'?
- Giorgos
^ permalink raw reply [flat|nested] 34+ messages in thread
* shell-mode flakey [was Re: message-confirm-send]
2007-11-15 23:08 ` message-confirm-send Russ Allbery
2007-11-15 23:38 ` message-confirm-send jidanni
2007-11-15 23:58 ` message-confirm-send Miles Bader
@ 2007-12-18 5:24 ` jidanni
[not found] ` <mailman.5147.1197955487.18990.bug-gnu-emacs@gnu.org>
3 siblings, 0 replies; 34+ messages in thread
From: jidanni @ 2007-12-18 5:24 UTC (permalink / raw)
To: ding; +Cc: bug-gnu-emacs
RussA> I consider the rm -i alias to be useless.
Yeah well homeboy consider the case of emacs shell-mode as it offers
line buffering vs. character buffering, ideal for transpacific site
administration.
As one can not be exactly sure if "rm bla*" got sent intact as
sometimes has been my experience (bits of prompt sent, bits of command
not sent, but what can you demand it this cut and paste world), it's
nice to have the remote side ask you "are you sure?".
Indeed, even if I was using xterm, you never know what bumping the
mouse the wrong way might send from the current clipboard. Maybe SPACE
RETURN just when the cursor was in the wrong spot.
And of course for we Geritol clubbers, what if one becomes deceased
and one's chin hits SPC and nose hits RET. Do you want to be
remembered by your community club as that guy who deleted all the
files?
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <mailman.5147.1197955487.18990.bug-gnu-emacs@gnu.org>]
* Re: shell-mode flakey
[not found] ` <mailman.5147.1197955487.18990.bug-gnu-emacs@gnu.org>
@ 2007-12-18 16:19 ` Roland Winkler
2007-12-19 0:31 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Roland Winkler @ 2007-12-18 16:19 UTC (permalink / raw)
To: jidanni; +Cc: bug-gnu-emacs, ding
jidanni@jidanni.org writes:
> And of course for we Geritol clubbers, what if one becomes deceased
> and one's chin hits SPC and nose hits RET. Do you want to be
> remembered by your community club as that guy who deleted all the
> files?
Somewhat off-topic: I once discussed the following on
bug-coreutils@gnu.org.
I have
alias rm='rm --interactive'
But what I really would like was an interactive query that was
restricted to those cases when I have typed something on the command
line that doesn't tell me what rm will really do. Usually, this is
the case when the shell did some filename expansion. Unfortunately,
to the best of my knowledge it is not possible for a command like rm
to figure out whether the command shell performed some kind of
filename expansion or not.
When I discussed this some time ago with one of the bash
maintainers, he said that he had just recovered all files of a
colleague who had typed "rm foo *" instead of "rm foo*". For those
and only those cases I'd like to have a reliable interactive query
before rm will do its job.
How is emacs' shell mode implemented? I use it more and more often
instead of a "plain terminal". Could it distinguish between these
cases?
Roland
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: shell-mode flakey
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>
2 siblings, 0 replies; 34+ messages in thread
From: Miles Bader @ 2007-12-19 0:31 UTC (permalink / raw)
To: Roland Winkler; +Cc: bug-gnu-emacs, ding, jidanni
Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> writes:
> When I discussed this some time ago with one of the bash
> maintainers, he said that he had just recovered all files of a
> colleague who had typed "rm foo *" instead of "rm foo*". For those
> and only those cases I'd like to have a reliable interactive query
> before rm will do its job.
One simple possibility might be a "--query-if-multiple" option, which
would act like -i if there was more than one command-line filename
argument.
That wouldn't help for all cases, but I think it would catch a large
proportion of common typos...
-Miles
--
`There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.'
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: shell-mode flakey
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>
2 siblings, 0 replies; 34+ messages in thread
From: Russ Allbery @ 2007-12-19 2:22 UTC (permalink / raw)
To: ding, bug-gnu-emacs
Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> writes:
>
> Somewhat off-topic: I once discussed the following on
> bug-coreutils@gnu.org.
>
> I have
>
> alias rm='rm --interactive'
>
> But what I really would like was an interactive query that was
> restricted to those cases when I have typed something on the command
> line that doesn't tell me what rm will really do. Usually, this is
> the case when the shell did some filename expansion. Unfortunately,
> to the best of my knowledge it is not possible for a command like rm
> to figure out whether the command shell performed some kind of
> filename expansion or not.
Yeah, this is the reason why tcsh implements this in the shell rather than
in rm. set rmstar in tcsh will cause tcsh to warn about the command rm
with an argument of * before it expands the wildcard, which is far more
useful than rm -i because it only prompts for an infrequent operation. I
wish bash had that feature; it's one of the main things left that tcsh
will do that bash won't (so far as I know).
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <mailman.5185.1198024311.18990.bug-gnu-emacs@gnu.org>]
* Re: shell-mode flakey
[not found] ` <mailman.5185.1198024311.18990.bug-gnu-emacs@gnu.org>
@ 2007-12-19 16:25 ` Sven Joachim
0 siblings, 0 replies; 34+ messages in thread
From: Sven Joachim @ 2007-12-19 16:25 UTC (permalink / raw)
To: Miles Bader; +Cc: bug-gnu-emacs, jidanni, ding, Roland Winkler
On 2007-12-19 01:31 +0100, Miles Bader wrote:
> Roland Winkler <Roland.Winkler@physik.uni-erlangen.de> writes:
>> When I discussed this some time ago with one of the bash
>> maintainers, he said that he had just recovered all files of a
>> colleague who had typed "rm foo *" instead of "rm foo*". For those
>> and only those cases I'd like to have a reliable interactive query
>> before rm will do its job.
>
> One simple possibility might be a "--query-if-multiple" option, which
> would act like -i if there was more than one command-line filename
> argument.
>
> That wouldn't help for all cases, but I think it would catch a large
> proportion of common typos...
In coreutils 6.0 and higher, a similar option is implemented. From the
NEWS file:
,----
| rm now accepts the -I (--interactive=once) option. This new option
| prompts once if rm is invoked recursively or if more than three
| files are being deleted, which is less intrusive than -i prompting
| for every file, but provides almost the same level of protection
| against mistakes.
`----
Cheers,
Sven
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 22:47 ` message-confirm-send jidanni
2007-11-15 22:55 ` message-confirm-send Karl Kleinpaste
2007-11-15 23:08 ` message-confirm-send Russ Allbery
@ 2007-11-17 9:23 ` Reiner Steib
2007-11-25 3:20 ` message-confirm-send Giorgos Keramidas
3 siblings, 0 replies; 34+ messages in thread
From: Reiner Steib @ 2007-11-17 9:23 UTC (permalink / raw)
To: ding
On Thu, Nov 15 2007, jidanni@jidanni.org wrote:
> 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'
Here's what I have in my shell init files...
unalias cp mv rm ln 2>/dev/null
Aliasing these commands is evil because one day you'll use them
expecting confirmation when the alias is not present, say on a
different system or through a shell which didn't read the init file
for some reason.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-15 22:47 ` message-confirm-send jidanni
` (2 preceding siblings ...)
2007-11-17 9:23 ` message-confirm-send Reiner Steib
@ 2007-11-25 3:20 ` Giorgos Keramidas
2007-11-26 12:51 ` message-confirm-send jidanni
3 siblings, 1 reply; 34+ messages in thread
From: Giorgos Keramidas @ 2007-11-25 3:20 UTC (permalink / raw)
To: jidanni; +Cc: ding
On 2007-11-16 06:47, jidanni@jidanni.org wrote:
> 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
I'm not a manly type, but I find these exact aliases extremely annoying
when they are *forced* upon every user of a system, i.e. by an admin who
wants to "protect newbies" and adds them to `/etc/bashrc'.
In fact, in one of the systems I use, I have the following in my own
`.bashrc' to undo the silliness of `/etc/bashrc':
# Undo the braindead aliases diogenis forces on all users.
unalias rm mv cp > /dev/null 2>&1
What does this have to do with Gnus and `C-c C-c' though?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: message-confirm-send
2007-11-25 3:20 ` message-confirm-send Giorgos Keramidas
@ 2007-11-26 12:51 ` jidanni
0 siblings, 0 replies; 34+ messages in thread
From: jidanni @ 2007-11-26 12:51 UTC (permalink / raw)
To: ding
>> alias rm='rm -i'
GK> What does this have to do with Gnus and `C-c C-c' though?
I'm the kind of guy that is saying something similar to "please add an
-i option to rm, so that some users may, if they so chose, do alias
rm='rm -i'.
> Maybe an agentized session is something which the original poster may
> consider as an `improved mode of using Gnus'?
Yes that and directly editing /var/spool/exim4/input/* is nice when
one's modem is not connected. However I am sure gnus is not so
dangerous that it cannot be directly connected to the Internet, with
the exception of the repeated prefix key (C-c C-c) that might get hit
before one has removed Cc: FBI from the header, landing one in RISKS
digest.
Anyway, the idea is give the users a variable he can toggle, instead
of making him research how to "enhance rm to now also have a rm -i
option", bloating one's http://jidanni.org/comp/.gnus.el file even further.
^ permalink raw reply [flat|nested] 34+ messages in thread