Re: message-confirm-send

[Bruno Tavernier <tavernier.bruno@gmail.com>]

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