bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Drew Adams]

This is ridiculous.  Can't you define a simple UI for sending a bug
report using emacs -Q?  It goes from bad to worse!
 
Not only do users still need to jump through the same silly hoops (edit
the `From' field from its "...tickle" silliness, etc.), but now you make
them answer another question, with 4 paragraphs(!) of explanation to try
to make it clear.  Those paragraphs alone should be a signal to you that
you are on the WRONG TRACK.
 
 "Send mail via: 
 
  Emacs is about to send an email message, but it has not been
  configured for sending email.  To tell Emacs how to send email:
 
  - Type `mail client' to start your default email client and
    pass it the message text.
 
  - Type `smtp' to send mail directly to an "outgoing mail" server.
    (Emacs may prompt you for SMTP settings).
 
  Emacs will record your selection and will use it thereafter.
  To change it later, customize the option `send-mail-function'."
 
And no, Emacs is NOT "about to send an email message" - not if you use
your own mail client.  You are still so Gnus-centric that you cannot see
the forest for the trees.
 
Users reporting a bug with emacs -Q SHOULD NOT HAVE TO "tell Emacs how
to send email".  Emacs does NOT need to know how to send email if a user
has a mail client.  And Emacs does NOT need to SEND email in that case.
 
And NO, Emacs will NOT record your selection and use it thereafter.  Not
if you are using emacs -Q.
 
This boilerplate is totally inappropriate for emacs -Q, and it should be
removed even when a user init file is used.
 
You need to totally rethink/redesign this nonsense.  There was ZERO
problem in prior Emacs releases: Users could send a bug report using
emacs -Q without jumping through ANY hoops.  This is only a regression.
 
You made a giant leap BACKWARD.  Now you've moved even further BACKWARD.
And you're still headed BACKWARD.
 
Try to think of the USERS.  Think of a newbie who tries to help you by
sending a bug report using emacs -Q (as you request).  And stop thinking
so much about promoting Emacs as an email client - that has, apparently,
been behind all of this misguided silliness.
 
 
 
In GNU Emacs 24.0.90.1 (i386-mingw-nt5.1.2600)
 of 2011-10-24 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags
-I"D:/devel/emacs/libs/libXpm-3.5.8/include"
-I"D:/devel/emacs/libs/libXpm-3.5.8/src"
-I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
-I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include"
-I"D:/devel/emacs/libs/giflib-4.1.4-1/include"
-I"D:/devel/emacs/libs/jpeg-6b-4/include"
-I"D:/devel/emacs/libs/tiff-3.8.2-1/include"
-I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags
-L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'
 

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Stefan Monnier]

> Not only do users still need to jump through the same silly hoops (edit
> the `From' field from its "...tickle" silliness, etc.), but now you make

This bug is still open indeed.  Lars said he hand an idea of how to work
around it, but I haven't heard from him since.

> And no, Emacs is NOT "about to send an email message"

Yes it is.  The message is currently in an Emacs buffer and it needs to
go to the destination host, and a command told Emacs to "do it".
So yes, it's about to send an email.  Maybe it will do so via the user's
MUA with some user interaction along the way, tho.

If you can suggest better wording, please do.

> Users reporting a bug with emacs -Q SHOULD NOT HAVE TO "tell Emacs how
> to send email".

Hmm... should I call that "mail client centric"?
There is no reliable way to send email in general without asking
the user.  It sucks, but that's how it is.  Please please please pretty
please stop bitching about it because there is nothing we can do about it.

> Emacs does NOT need to know how to send email if a user
> has a mail client.

What is that I see?  Oh, right an "if", great!

> And NO, Emacs will NOT record your selection and use it thereafter.  Not
> if you are using emacs -Q.

Then don't use "emacs -Q" to send bug reports.  It's an idiotic idea anyway.

> You need to totally rethink/redesign this nonsense.

And you need to totally rethink your attitude and use of the caps lock key.


        Setfan

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Wed, 26 Oct 2011 10:46:43 -0700
> 
> And NO, Emacs will NOT record your selection and use it thereafter.

Yes, it will: if you send another message from the same Emacs session,
it will not ask you again.

Or would you suggest that we add a few more question about whether to
store the info on a file?

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Drew Adams]

> > And NO, Emacs will NOT record your selection and use it thereafter.
>                                                    ^^^^^^^^^^^^^^^^^
> 
> Yes, it will: if you send another message from the same Emacs session,
> it will not ask you again.

I stand corrected, if "thereafter" is necessarily limited in meaning to the same
Emacs session.  Otherwise, no, the text is misleading and inaccurate.

As is the subsequent text:
 "To change it later, customize the option `send-mail-function'."

If you are talking about the `emacs -Q' session, then that text too is
inaccurate - it does not apply.  Or is the user supposed to guess that you are
suddenly switching from same-session "thereafter" to future session "later"?

You are apparently seeking to defend this inaccuracy at all costs.
Why not just recognize it and fix it, instead?

Just say what really happens: If `emacs -Q' then you won't be bugged again for
the rest of the session.  Otherwise, you won't ever be bugged again.

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Drew Adams]

> > Users reporting a bug with emacs -Q SHOULD NOT HAVE TO 
> > "tell Emacs how to send email".
> 
> Hmm... should I call that "mail client centric"?

No, call it "keep it simple" and "don't `fix' what ain't broke".

> There is no reliable way to send email in general without asking
> the user.

Tell that to Emacs up through version 23.

> > Emacs does NOT need to know how to send email if a user
> > has a mail client.
> 
> What is that I see?  Oh, right an "if", great!

And yet, even _if_ a user has a mail client s?he _still_ has to tell Emacs (now)
how to send email.  That's the point.  Not "great!".

And that "if" is a commonly satisfied "if", and it is becoming ever more common
with the widespread use of mobile devices.  Save the configuration of
Emacs-as-emailer for when a user _asks_ how to configure it as an emailer: on
demand only.

> > And NO, Emacs will NOT record your selection and use it 
> > thereafter.  Not if you are using emacs -Q.
> 
> Then don't use "emacs -Q" to send bug reports.  It's an 
> idiotic idea anyway.

1. The text makes no sense if you are reporting a bug with `emacs -Q'.  That's
the point.

2. No, it is not an idiotic idea to use `emacs -Q to send bug reports.  In fact:

 "If at all possible, give a full recipe for an Emacs started with the
  `-Q' option (*note Initial Options::).  This bypasses your
  `.emacs' customizations."  -- `(emacs) Checklist'

That's about the recipe, admittedly.  But Emacs also automatically inserts lots
of info about the current session into the mail body.  Obviously, if the recipe
is for `emacs -Q', it  makes sense for this session info to also reflect that
same context.

Marshalling and sending session settings for a context that is totally different
from that of the recipe is at best useless and at worst misleading and error
prone.  Not to mention that if you go to the trouble of reproducing the problem
with `emacs -Q' then you might as well report it from that same session.

Not to want to clearly, cleanly, and simply support reporting bugs from an
`emacs -Q' session is truly misguided.  With that outlook, you might as well
remove sending a bug report from the Help menu when `emacs -Q', and have
`report-emacs-bug' simply raise an error if invoked from an `emacs -Q' session.

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <9877@debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 13:04:00 -0700
> 
> Just say what really happens: If `emacs -Q' then you won't be bugged again for
> the rest of the session.  Otherwise, you won't ever be bugged again.

Which is longer and more confusing.

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Drew Adams]

> Which is longer and more confusing.

Which is yet another sign that this UI is unclean, inherently confusing, and
overly complicated.

If you have to distinguish `emacs -Q' in various ways in the instructions for
reporting a bug, in order to make things clear, then something is wrong.  Keep
it simple, as before: `C-c C-c y'.

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Drew Adams]

> Please please please pretty please stop bitching about it
> because there is nothing we can do about it.

If it weren't for such bug reports you never would have addressed any of the
problems with this that you've tried to tackle so far.  We'd still be stuck with
Lars's original bass ackwards questionaire from Hell.

That's quite clear from the fact (yes) that it took several raisings of the
question over a period of more than a year, those complaints/reports being
separated by long periods of waiting for some progress.

If you focus more on users and the quality of the product you'll have a better
attitude toward and appreciation of "bitching" by users.

bug#9877: 24.0.90; `report-emacs-bug' is even more broken now

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <9877@debbugs.gnu.org>
> Date: Wed, 26 Oct 2011 13:25:35 -0700
> 
> If you have to distinguish `emacs -Q' in various ways in the instructions for
> reporting a bug, in order to make things clear

But we don't have to.  The text is correct as written.