Re: smtp crap

[Tim Cross]

On Wed, Oct 12, 2011 at 3:24 AM, Drew Adams <address@hidden> wrote:
>> > But MOST importantly, what about reporting bugs with `emacs -Q'?
>> >
>> > That is the real problem here, and the one that you keep
>> > ignoring.  Instead, you keep focusing on the problem of
>> > customization, which is, relatively speaking, no big deal
>> > (assuming you finish fixing the repeated-interrogation bugs).
>>
>> No, that's not the real problem.
>
> To me it is.  It is a more important problem than how to help users configure
> Emacs to use email.
>
>> There are two problems:
>> (1) What should Emacs do when the user asks it to send an email?
>> (2) What should Emacs do when the user asks it to report a bug?
>
> Agreed.
>
>> This series of questions is appropriate in scenario 1, but not in
>> scenario 2.
>
> I would say that _some email configuration UI_ is appropriate for #1, but not
> for #2.
>
> But "some config UI" does not imply "this series of questions".
>
> I don't really care too much (personally) about what UI is used for #1.  But
> (FWIW) my advice would be for Emacs to (a) not _initiate_ that UI but only
> provide it upon _user request_ and (b) probably not offer it as a sequence of
> questions (e.g. wizard) at all, but rather as a form (e.g. checkboxes) to fill
> in.  Look at how other apps help users configure email, for some 
> inspiration...
>
>> (Especially with `emacs -Q', which causes an already-configured
>> Emacs to explicitly ignore its configuration.)
>
> Exactly.  This is important.  It should be the starting point.
>
> The fact that the UI interrogation-sequence-from-hell was (initially) 
> completely
> backward (see the bugs, some of which have been fixed), and that it is still,
> well, weird, reflects the fact that this was NOT the starting point, even 
> though
> the configuration dialog is initiated by the `report-emacs-bug' code.
>
>> The fact that the two scenarios are related is an implementation
>> detail of report-emacs-bug.
>
> It might be currently, but it should not be.
>
>> The argument Drew is making would disappear instantly if
>> report-emacs-bug sent an HTTP POST request, for instance.
>
> Yes.  But in that case Drew would argue that we should still also let users
> report bugs using email.  On this I support Richard's stance: users should be
> able to report bugs using email.  AND they should be able to do so using HTTP.
>
> We should make it as easy as possible for a user to report an Emacs bug,
> especially using `emacs -Q'.  That should be the priority - the rest is
> secondary, IMHO.  And yes, this _should_ be a no-brainer.
>
>
>
>

Totally agree - address the issue of bug reporting and most of this
kludgy mess goes away.

and please, DO NOT jump through all sorts of hoops with -Q to enable
'special' configuration settings to exist - the whole idea of -Q is
that it is a base, well known and repeatable configuration. Once you
start making exceptions that whole premise is lost. Using -Q should
allow me to have exactly the same configuration as someone else who
also runs -Q - it should not be 'the same configuration except for
....' If this means that users cannot submit bugs using emacs as their
MUA when running -Q it does not mean we need to hack at custom or make
exceptions - it means that email is not the right solution for
submitting bug messages when running under -Q. By all means, allow it
for other contexts, even make it the default for people who do
configure emacs as their MUA, but not when running under -Q and not
for those who do not configure emacs as a their MUA.


Tim
-- 

Tim Cross