RE: smtp crap

[Drew Adams]

> pretty clearly answers the question ``Why burden and confuse
> users now?''.

No, it does not.  It neither justifies the burden and confusion nor explains why
_now_.

If as you say the problem is real and not new, why now?  Why didn't RMS et al
tackle it many, many moon ago?  Wasn't it important enough?  Fewer mails sat
idle in local queues back then?  I foresee your answer: email is more
complicated now.  Tough.  That's not a reason for Emacs to act idiotically.

> > The solution is to simply _mention_ in the bug-report 
> > instructions that "IF you have no mail client and
> > IF you have not yet configured Emacs itself as a mailer,
> > THEN invoke `M-x XYZ' to so configure it.", where XYZ is a 
> > command that leads you down whatever configuration garden path
> > is required.
> 
> So, you want to ask the user,

No. read what I said.  I do _not_ want Emacs to ask the user anything here.
That's the point, in fact.

> in the middle of reporting a bug, to notice that there's a warning

I did not mention "warning".  The instructions and information we give to users
preparing a bug report, including what I suggested, are not "warnings".

> somewhere, and then guess whether or not emacs can send mail
> without extra steps on their part,

Absolutely not.  Read what I wrote: "If _you_ have not yet configured...".

There is nothing requiring the user to guess whether Emacs might be able to send
mail.

> when we know that a common failure mode is ``it doesn't work and
> the user can't reasonably know that it didn't/won't work''.

The user will reasonably know whether s?he has an email client (can send mail
outside Emacs).  The user will reasonably know whether s?he has already
explicitly configured Emacs itself for email.  There are of course always some
users who fall outside of "reasonable".  And yes, knowledgable user X might lend
his machine and Emacs to ignorant user Y.  Stuff happens.

We have never even tried mentioning this to users.  Who knows how many of the
"reasonable" users you cite would still end up with local mail queues full of
bug reports, if we simply informed them.

We might also mention to them that they will receive a confirmation email, if
sending their bug report is successful.  How many unsuccessful bug reports do
you think will fill up the local queues of "reasonable" users if we tell them to
expect an ACK mail?

Will users read all of this info each time they prepare a bug report?  Of course
not.  But they will likely read it the first time.  And there's no reason not to
let them know these things.

> Seems like a pretty poor default to me. YMMV.

We've seen the solution you favor.

Even a simple `mailto:' would, in most cases, cause a user with no SMTP
configured and no other support for `mailto:' to see an error raised (e.g. by a
browser).  Why assume that Emacs must blindly remain silent over and over,
simply filling up a local mail queue with bug reports?

I'm no expert on email, but I know a lousy UI when I see one.  If it weren't for
my complaints and those by a few others (e.g. Miles), we would still have the
bass ackwards dialog that Lars originally implemented to solve this problem.
That solution drew no objection from the Emacs maintainers or other developers
arguing your position.

Just because you can recognize a problem does not mean that you have found a
proper solution.  Burdening and confusing _all_ users is not the right way to
avoid having a few users think they sent email when they didn't.  Try harder.