message-confirm-send

message-confirm-send

[jidanni]

Gentlemen, do you realize how easy it is to hit C-c C-c by accident
while composing an email?

You could send something half-baked to a mailing list of important
people!

Ask yourselves: does e.g., mutt(1) not need a "y" confirmation to
actually send something?

So how does one switch on confirmation mode? I don't see exactly such
a variable in message.el.

OK, you forced me to do
(defun jidanni-message-confirm ()
  "Confirm that we really want to send the message."
  (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
(add-hook 'message-send-hook 'jidanni-message-confirm)
At least add an example to the manual.

Imagine sending a mail to people you respect, cut off in mid-

Re: message-confirm-send

[Adam Sjøgren]

On Thu, 15 Nov 2007 02:58:28 +0800, jidanni@jidanni.org wrote:

> Gentlemen, do you realize how easy it is to hit C-c C-c by accident
> while composing an email?

Do you realize how often you hit C-c C-c *on purpose* to send an email?

I dislike computer systems that ask for confirmation of every command
issued often.

> You could send something half-baked to a mailing list of important
> people!

You will quickly get "C-c C-c y" imprinted in your fingers instead of
"C-c C-c", and then you have gained nothing but annoyance.

What will your next step then be - adding a delay before the 'y' is
accepted so the habituated user is forced to think about it?

Couldn't the user just have thought about pressing C-c C-c in the first
place, then?

> Ask yourselves: does e.g., mutt(1) not need a "y" confirmation to
> actually send something?

Doesn't mutt call a separate editor for editing the body of the email? 
That makes it necessary for mutt to have a seperate step for changing
Cc, Bcc, etc. afterwards, i.e. a prompt.

> Imagine sending a mail to people you respect, cut off in mid-

Yeah, those people would not forgive you and certainly never talk to you
again.


  Best regards,

-- 
 "parsley, sage, rosemary and KOMPRESSOR"                     Adam Sjøgren
                                                         asjo@koldfront.dk

Re: message-confirm-send

[Leo]

On 2007-11-14 21:05 +0000, Adam Sjøgren wrote:
>> Gentlemen, do you realize how easy it is to hit C-c C-c by accident
>> while composing an email?
>
> Do you realize how often you hit C-c C-c *on purpose* to send an email?
>
> I dislike computer systems that ask for confirmation of every command
> issued often.

I agree with Adam.

99.9% when I hit C-c C-c, I do want to send the email. In fact I barely
remember the last time I sent a half-finished email.

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

          Use the best OS -- http://www.fedoraproject.org/

Re: message-confirm-send

[Bastien]

jidanni@jidanni.org writes:

> Gentlemen, do you realize how easy it is to hit C-c C-c by accident
> while composing an email?

Not that easy IMO. 

> Ask yourselves: does e.g., mutt(1) not need a "y" confirmation to
> actually send something?

So the joke is that nobody will have the footnote (1) and will be able
to ever know whether mutt does have such a neat feature.  Funny.

> So how does one switch on confirmation mode? I don't see exactly such
> a variable in message.el.
>
> OK, you forced me to do
> (defun jidanni-message-confirm ()
>   "Confirm that we really want to send the message."
>   (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
> (add-hook 'message-send-hook 'jidanni-message-confirm)
> At least add an example to the manual.

Please make your code readable.  

> Imagine sending a mail to people you respect, cut off in mid-
le of a sentence that wasn't even worth starting.  

Yeah, I can imagine that :)

-- 
Bastien

Re: message-confirm-send

[jidanni]

C-c C-c is too very easy to hit by accident. A few milliseconds is all
it takes to make a buffoon of oneself.
$ grep ' r ' .xsession
xset r rate 250 30 m 5 7
Especially in gnus packed with its C-c prefix keys.
Yes, I'm a C-c (si ssy).

Re: message-confirm-send

[Bastien]

jidanni@jidanni.org writes:

> C-c C-c is too very easy to hit by accident. A few milliseconds is all
> it takes to make a buffoon of oneself.

I can't believe you typed the sentence above in a few milliseconds.

-- 
Bastien

Re: message-confirm-send

[jidanni]

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

Re: message-confirm-send

[Karl Kleinpaste]

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.

Re: message-confirm-send

[Russ Allbery]

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/>

Re: message-confirm-send

[jidanni]

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.

Re: message-confirm-send

[Miles Bader]

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'

Re: message-confirm-send

[Russ Allbery]

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/>

Re: message-confirm-send

[Miles Bader]

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

Re: message-confirm-send

[Reiner Steib]

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/

Re: message-confirm-send

[Bastien]

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

Re: message-confirm-send

[Ted Zlatanov]

On Wed, 14 Nov 2007 21:09:48 +0000 Leo <sdl.web@gmail.com> wrote: 

L> On 2007-11-14 21:05 +0000, Adam Sjøgren wrote:
>>> Gentlemen, do you realize how easy it is to hit C-c C-c by accident
>>> while composing an email?
>> 
>> Do you realize how often you hit C-c C-c *on purpose* to send an email?
>> 
>> I dislike computer systems that ask for confirmation of every command
>> issued often.

L> I agree with Adam.

L> 99.9% when I hit C-c C-c, I do want to send the email. In fact I barely
L> remember the last time I sent a half-finished email.

Also agreed.  I do think, however, a very useful message send hook would
be one that checks if the message contains the words

attach.*
enclosed.*file

plus the equivalents in a few other languages.  If those are found, it
will ask for confirmation before sending if the message contains no
attachments.  I have sent messages without the attachments they were
supposed to have many times, so I think this would be great.

Ted

Re: message-confirm-send

[Giorgos Keramidas]

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?

Re: message-confirm-send

[Giorgos Keramidas]

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

Re: message-confirm-send

[jidanni]

>> 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.

Re: message-confirm-send

[jidanni]

Just the other day I was in picture-mode putting a big X on a
paragraph. Two C-c C-c's leave picture-mode, four sends the message...

Re: message-confirm-send

[Reiner Steib]

On Thu, Dec 06 2007, jidanni@jidanni.org wrote:

> Just the other day I was in picture-mode putting a big X on a
> paragraph. Two C-c C-c's leave picture-mode, four sends the message...

Advise `message-send-and-exit' to have whatever confirmation you like
and/or undefine `C-c C-c'.  No need for message-confirm-send or
somesuch.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: message-confirm-send

[jidanni]

R> Advise `message-send-and-exit' to have whatever confirmation you like

I found and browsed advice.el, where apparently how to do this is
documented. However it is overwhelming as usual. So thanks anyway.

shell-mode flakey [was Re: message-confirm-send]

[jidanni]

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?

Re: shell-mode flakey

[Roland Winkler]

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

Re: shell-mode flakey

[Miles Bader]

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.'

Re: shell-mode flakey

[Russ Allbery]

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/>

Re: shell-mode flakey

[Sven Joachim]

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

Re: message-confirm-send

[Lars Magne Ingebrigtsen]

jidanni@jidanni.org writes:

> OK, you forced me to do
> (defun jidanni-message-confirm ()
>   "Confirm that we really want to send the message."
>   (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
> (add-hook 'message-send-hook 'jidanni-message-confirm)
> At least add an example to the manual.
>
> Imagine sending a mail to people you respect, cut off in mid-

Heh heh heh.

Well, I've sent more than my share of messages prematurely by leaning on
`C-c C-c', so I'm sympathetic, but on the other hand, all equivalent
Emacs things (like checking in stuff into VCs) work with `C-c C-c'
without any "warning".  So I think it should remain that way.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: message-confirm-send

[jidanni]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
LMI> jidanni@jidanni.org writes:

>> OK, you forced me to do
>> (defun jidanni-message-confirm ()
>> "Confirm that we really want to send the message."
>> (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
>> (add-hook 'message-send-hook 'jidanni-message-confirm)
>> At least add an example to the manual.
>> 
>> Imagine sending a mail to people you respect, cut off in mid-

LMI> Heh heh heh.

LMI> Well, I've sent more than my share of messages prematurely by leaning on
LMI> `C-c C-c', so I'm sympathetic, but on the other hand, all equivalent
LMI> Emacs things (like checking in stuff into VCs) work with `C-c C-c'
LMI> without any "warning".  So I think it should remain that way.

Yeah with VCs you could just check it back out. But with email you have
to send apologies, unless you already sent the corporate secrets due to
cut and paste errors.

Do provide the function but leave the variable to activate it off. That way
users could just toggle a variable instead of having to muck around
writing their own hack.

Re: message-confirm-send

[Alberto Luaces]

jidanni@jidanni.orgwrites:

>>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> LMI> jidanni@jidanni.org writes:
>
>>> OK, you forced me to do
>>> (defun jidanni-message-confirm ()
>>> "Confirm that we really want to send the message."
>>> (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
>>> (add-hook 'message-send-hook 'jidanni-message-confirm)
>>> At least add an example to the manual.
>>> 
>>> Imagine sending a mail to people you respect, cut off in mid-
>
> LMI> Heh heh heh.
>
> LMI> Well, I've sent more than my share of messages prematurely by leaning on
> LMI> `C-c C-c', so I'm sympathetic, but on the other hand, all equivalent
> LMI> Emacs things (like checking in stuff into VCs) work with `C-c C-c'
> LMI> without any "warning".  So I think it should remain that way.
>
> Yeah with VCs you could just check it back out. But with email you have
> to send apologies, unless you already sent the corporate secrets due to
> cut and paste errors.
>
> Do provide the function but leave the variable to activate it off. That way
> users could just toggle a variable instead of having to muck around
> writing their own hack.

What about just mapping also `C-c C-c' to `message-dont-send' if you
want to reread before sending?

-- 
Alberto

Re: message-confirm-send

[Richard Riley]

Alberto Luaces <aluaces@udc.es> writes:

> jidanni@jidanni.orgwrites:
>
>>>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> LMI> jidanni@jidanni.org writes:
>>
>>>> OK, you forced me to do
>>>> (defun jidanni-message-confirm ()
>>>> "Confirm that we really want to send the message."
>>>> (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
>>>> (add-hook 'message-send-hook 'jidanni-message-confirm)
>>>> At least add an example to the manual.
>>>> 
>>>> Imagine sending a mail to people you respect, cut off in mid-
>>
>> LMI> Heh heh heh.
>>
>> LMI> Well, I've sent more than my share of messages prematurely by leaning on
>> LMI> `C-c C-c', so I'm sympathetic, but on the other hand, all equivalent
>> LMI> Emacs things (like checking in stuff into VCs) work with `C-c C-c'
>> LMI> without any "warning".  So I think it should remain that way.
>>
>> Yeah with VCs you could just check it back out. But with email you have
>> to send apologies, unless you already sent the corporate secrets due to
>> cut and paste errors.
>>
>> Do provide the function but leave the variable to activate it off. That way
>> users could just toggle a variable instead of having to muck around
>> writing their own hack.
>
> What about just mapping also `C-c C-c' to `message-dont-send' if you
> want to reread before sending?

C-c C-c is ingrained as "process".

I would agree that the confirm could and should be built in
however. Possibly based on a group parameter "Prompt to confirm
post". Defaulted to nil so default stays the same.

Re: message-confirm-send

[Bruno Tavernier]

Richard Riley <rileyrg@googlemail.com> writes:

> Alberto Luaces <aluaces@udc.es> writes:
>
>> jidanni@jidanni.orgwrites:
>>
>>>>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> LMI> jidanni@jidanni.org writes:
>>>
>>>>> OK, you forced me to do
>>>>> (defun jidanni-message-confirm ()
>>>>> "Confirm that we really want to send the message."
>>>>> (interactive)(or (y-or-n-p "Send?")(keyboard-quit)))
>>>>> (add-hook 'message-send-hook 'jidanni-message-confirm)
>>>>> At least add an example to the manual.

>>> LMI> Well, I've sent more than my share of messages prematurely by leaning on
>>> LMI> `C-c C-c', so I'm sympathetic, but on the other hand, all equivalent
>>> LMI> Emacs things (like checking in stuff into VCs) work with `C-c C-c'
>>> LMI> without any "warning".  So I think it should remain that way.
>>>
>>> Yeah with VCs you could just check it back out. But with email you have
>>> to send apologies, unless you already sent the corporate secrets due to
>>> cut and paste errors.
>>>
>>> Do provide the function but leave the variable to activate it off. That way
>>> users could just toggle a variable instead of having to muck around
>>> writing their own hack.
>>
>> What about just mapping also `C-c C-c' to `message-dont-send' if you
>> want to reread before sending?
>
> C-c C-c is ingrained as "process".
>
> I would agree that the confirm could and should be built in
> however. Possibly based on a group parameter "Prompt to confirm
> post". Defaulted to nil so default stays the same.

I probably read the thread too quickly, but isn't the variable
`message-confirm-send' doing what you asked?

In my .gnus, I have
,----
| (setq message-confirm-send t)
`----
and no more messages send by mistake... ;-)

-- 
Bruno

Re: message-confirm-send

[jidanni]

>>>>> "BT" == Bruno Tavernier <tavernier.bruno@gmail.com> writes:

BT> I probably read the thread too quickly, but isn't the variable
BT> `message-confirm-send' doing what you asked?

I see, Lars was finally replying to a years old bug report, and we both
forgot that I already won the battle and my idea was already
implemented.

That's what happens when there is an isolated bugs@gnus.org address...

Re: message-confirm-send

[Ted Zlatanov]

On Sun, 24 Oct 2010 22:46:31 +0800 jidanni@jidanni.org wrote: 

>>>>>> "BT" == Bruno Tavernier <tavernier.bruno@gmail.com> writes:
BT> I probably read the thread too quickly, but isn't the variable
BT> `message-confirm-send' doing what you asked?

j> I see, Lars was finally replying to a years old bug report, and we both
j> forgot that I already won the battle and my idea was already
j> implemented.

j> That's what happens when there is an isolated bugs@gnus.org address...

Reminds me of the Japanese guys that came out of the jungle 29 years
after the war ended.

http://en.wikipedia.org/wiki/Japanese_holdout

Ted