please review bug #13141

please review bug #13141

[Drew Adams]

This is about the info that gets automatically added to bug reports.

Stefan granted that most of that info is anyway useless, to him at least.
Jambunathan suggested a Boolean option to skip such info altogether.
 
I provided a patch that lets users customize which info to include.

Glenn simply tagged the bug `wontfix', saying "There is no need for such
complexity."


The patch is straightforward.  Please reconsider it.
Why not let users set the behavior they want for this?

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43

Re: please review bug #13141

[Alan Mackenzie]

Hi, Drew.

On Sat, Jan 19, 2013 at 03:10:09PM -0800, Drew Adams wrote:
> This is about the info that gets automatically added to bug reports.

> Stefan granted that most of that info is anyway useless, to him at least.
> Jambunathan suggested a Boolean option to skip such info altogether.

> I provided a patch that lets users customize which info to include.

> Glenn simply tagged the bug `wontfix', saying "There is no need for such
> complexity."


> The patch is straightforward.  Please reconsider it.
> Why not let users set the behavior they want for this?

I have to side with Glenn here.  We need to make Bug reporters' jobs as
simple as possible.  Sadly, there is a tendency for things which one
_can_ configure to become things that one _must_ configure - we know all
about this in Emacs - which would be most unfriendly for novice bug
reporters.

Let's keep this as simple as possible.

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: please review bug #13141

[Drew Adams]

> Jambunathan suggested a Boolean option to skip such info altogether.

I should have said that J. reminded that option
`report-emacs-bug-no-explanations' does that.

RE: please review bug #13141

[Drew Adams]

> > The patch is straightforward.  Please reconsider it.
> > Why not let users set the behavior they want for this?
> 
> I have to side with Glenn here.  We need to make Bug 
> reporters' jobs as simple as possible.

Why not give the individual bug reporters a say in what they think is simple?
Your idea of making their life easier might not be their idea.

Why does giving other users a choice bother you?
The default behavior would be the same as now.

> Sadly, there is a tendency for things which one _can_
> configure to become things that one _must_ configure -

I don't recognize any such tendency.  Give one example.

> we know all about this in Emacs

Well I don't know about it.  I've never seen the addition of a user option, with
no change to the default behavior, require any user to configure that option.

That's logically impossible.

If you do nothing then there is no change in behavior.  If you are unaware of
the option then your life is as simple as before.  If you are aware of it and IF
you want to take advantage of it, then you might even make life simpler for
yourself than before - but that's your choice.

> - which would be most unfriendly for novice bug reporters.

What would?  Giving a choice to any user who wants it?

> Let's keep this as simple as possible.

Let's give _users_ the choice.  Let's let them decide what is "as simple as
possible" for themselves, individually.

> > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43

Re: please review bug #13141

[Xue Fuqiao]

On Sat, 19 Jan 2013 15:59:45 -0800
"Drew Adams" <drew.adams@oracle.com> wrote:

> If you are unaware of
> the option then your life is as simple as before.  If you are aware of it and IF
> you want to take advantage of it, then you might even make life simpler for
> yourself than before - but that's your choice.

I think so, too.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

RE: please review bug #13141

[Stephen J. Turnbull]

Drew Adams writes:

 > Why not give the individual bug reporters a say in what they think
 > is simple?  Your idea of making their life easier might not be
 > their idea.

Why in the world do you think making life easier for bug *reporters*
deserves precedence?  The first principle of bug reporting is to get
useful information for the debuggers.  Over the 15 years that I've
been responding to bug reports, I've had at least half a dozen cases
where users deleted automatically added information which I then
requested -- to no avail, since the reporters never responded.  The
cases where users fail to include useful and readily available
information in plain ol' mail are legion.  In general, users are
notoriously poor judges of what information is useful.

It might be useful to hide the automatically generated information in
a MIME attachment, or add it at send time, and allow the user the
option of displaying/editing it.

 > Let's give _users_ the choice.  Let's let them decide what is "as
 > simple as possible" for themselves, individually.

Bug reporting is not an individual activity.  It is a community
activity, and the needs of developers must take precedence over users'
ideas of what's useful.  If you think some information is unnecessary,
argue it shouldn't be in the report in the first place, and get the
developers to agree.

Note that just because Stefan never uses the information doesn't mean
that other developers don't.

Re: please review bug #13141

[Xue Fuqiao]

On Sun, 20 Jan 2013 16:16:14 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> In general, users are
> notoriously poor judges of what information is useful.

But not all users.  We can add some notice (or maybe warning) in the
doc string of the user option and Emacs manual.

It seems that bug reporting in XEmacs and SXEmacs manuals is a little
poor: 
http://xemacs.org/Documentation/21.5/html/xemacs_30.html#SEC421
http://www.sxemacs.org/docs/sxemacs/Bugs.html#Bugs

-- 
http://www.gnu.org/software/emacs/manual/html_node/emacs/Bugs.html#Bugs

Re: please review bug #13141

[Alan Mackenzie]

Good Morning, Drew!

On Sat, Jan 19, 2013 at 03:59:45PM -0800, Drew Adams wrote:
> > > The patch is straightforward.  Please reconsider it.
> > > Why not let users set the behavior they want for this?

> > I have to side with Glenn here.  We need to make Bug 
> > reporters' jobs as simple as possible.

> Why not give the individual bug reporters a say in what they think is simple?
> Your idea of making their life easier might not be their idea.

My model of bug reporter, right now, is somebody considering submitting
their very first Emacs bug report

> Why does giving other users a choice bother you?
> The default behavior would be the same as now.

I've not seen the patch, but it is surely either a set of configuration
settings or a sequence of questions to be answered each time a new bug
report is done.  The former doesn't seem useful, since the useful info to
include will vary by bug report, not by bug submitter.  The latter would
be a burden on the bug reporter, and surely could come to be an
annoyance.

> > Sadly, there is a tendency for things which one _can_
> > configure to become things that one _must_ configure -

> I don't recognize any such tendency.  Give one example.

Er, CC Mode.

> > we know all about this in Emacs

> Well I don't know about it.  I've never seen the addition of a user option, with
> no change to the default behavior, require any user to configure that option.

That's a narrower case than I meant, I was talking more generally.  We
all have .emacses and I should think they are mostly biggish files.  I
would think there are few Emacs users without .emacses, if for nothing
more than customize-* settings.

> That's logically impossible.

> If you do nothing then there is no change in behavior.  If you are unaware of
> the option then your life is as simple as before.  If you are aware of it and IF
> you want to take advantage of it, then you might even make life simpler for
> yourself than before - but that's your choice.

> > - which would be most unfriendly for novice bug reporters.

> What would?  Giving a choice to any user who wants it?

To give somebody a choice is to inflict responsibility on her for
choosing.

> > Let's keep this as simple as possible.

> Let's give _users_ the choice.  Let's let them decide what is "as simple as
> possible" for themselves, individually.

I don't think users having this choice would be helpful.

> > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13141#43

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: please review bug #13141

[Xue Fuqiao]

On Sun, 20 Jan 2013 10:50:03 +0000
Alan Mackenzie <acm@muc.de> wrote:

> I've not seen the patch, but it is surely either a set of configuration
> settings or a sequence of questions to be answered each time a new bug
> report is done.  The former doesn't seem useful, since the useful info to
> include will vary by bug report, not by bug submitter.  The latter would
> be a burden on the bug reporter, and surely could come to be an
> annoyance.

I haven't seen the patch, either.  As for the latter, I think
`map-y-or-n-p' is a good choice, `!' in `query-replace-map' can act on
all following objects.

> I
> would think there are few Emacs users without .emacses, if for nothing
> more than customize-* settings.

I ever used Emacs without .emacs (except for custmize-* settings) for a long time, because:
1. I didn't know when to use `setq' and when to use `setq-default';
2. I wanted to add a load-path, but I didn't know what function I should use (`push' or `add-to-list');
3. I didn't know when to use `boundp', `fboundp' or `featurep';
4. I didn't know what feature to `require';
5. I didn't know the differences between `global-set-key' and `define-key';
And many other reasons.  I think I'm not the only one who met these problems.
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

Re: please review bug #13141

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sun, 20 Jan 2013 16:16:14 +0900
> Cc: 'Alan Mackenzie' <acm@muc.de>, 13141@debbugs.gnu.org, emacs-devel@gnu.org
> 
> Note that just because Stefan never uses the information doesn't mean
> that other developers don't.

Indeed, I do most of the time, and frequently find there valuable
information that I otherwise would have needed to ask for.

RE: please review bug #13141

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]

> > Why does giving other users a choice bother you?
> > The default behavior would be the same as now.
> 
> I've not seen the patch, but it is surely either a set of 
> configuration settings or a sequence of questions to be
> answered each time a new bug report is done.

It is simple to look at the patch.  Or if you want to try it, to see the option
(a single option) for yourself, you can load this tiny library that I just put
together quickly:
http://www.emacswiki.org/emacs-en/emacsbug%2b.el

(The code there is more complex than the patch version because it also provides
compatibility for older Emacs versions.)

And if loading that file is also too much trouble, then please at least take a
quick look at the attached screenshot to see what the option looks like.

(You can ignore any differences in the appearance from vanilla Emacs, e.g., the
additional buttons.  They are from my setup and are unrelated to this patch.
Just look at the option check boxes and doc string.)

> The former doesn't seem useful, since the useful info to
> include will vary by bug report, not by bug submitter.

It can vary by both.  The option just provides for a user to have her own,
customized default behavior, instead of being stuck with the one decided by
Emacs Dev.

And I agree with Dmitry's additional suggestion that we could provide a command
or commands to insert individual information items, e.g., the same items a user
can choose for the default behavior using the option:

* version info
* important settings list
* major mode
* minor modes
* recent input
* recent messages
* load-path shadows
* features

> The latter would be a burden on the bug reporter, and surely
> could come to be an annoyance.

You can be assured that I would never propose anything like that.  It should be
quite clear by know that I am not in favor of unnecessary interrogations when a
user tries to communicate with Emacs.  See, for example, bug #13506 and the long
history of such bug-report interrogation bugs over the last few years.

> > > Sadly, there is a tendency for things which one _can_
> > > configure to become things that one _must_ configure -
> 
> > I don't recognize any such tendency.  Give one example.
> 
> Er, CC Mode.

Sorry, I'm not familiar with it.  Can you elaborate?  Can you please show how
"the addition of a user option, with no change to the default behavior,
require[s] any user to configure that option"?  I cannot imagine that
possibility in this universe.

> > > we know all about this in Emacs
> 
> > Well I don't know about it.  I've never seen the addition 
> > of a user option, with no change to the default behavior,
> > require any user to configure that option.
> 
> That's a narrower case than I meant, I was talking more generally.

Oh.  Then maybe we are in agreement.  That is all that the patch I proposed
does.  It does not in any way change the default behavior.  At ease, please.

> To give somebody a choice is to inflict responsibility on her for choosing.

Not if the choice is not mandatory.  You need not even be aware of this choice.
That's why it's called an "option".

I would agree with you if this were about a mandatory grilling of the user,
making her reply to questions about things that s?he might not know or care
about.

That is not at all the case here.  You and any other users can totally ignore
this option and go on your business as before, with no change in behavior.
Emacs will leave you alone.

> I don't think users having this choice would be helpful.

Perhaps your thinking was based on some confusion about what this does?  See if
what I've explained above about it doesn't change your mind.

[-- Attachment #2: throw-report-emacs-bug-included-fields.png --]
[-- Type: image/png, Size: 38331 bytes --]

bug#13141: please review bug #13141

[Richard Stallman]

    I've had at least half a dozen cases
    where users deleted automatically added information which I then
    requested -- to no avail, since the reporters never responded.

To go out of their way to delete it makes me wonder why.  Maybe it was
a valid reason.  Could it be that there was something private in that
information which they specifically did not want to send?

Because of this consideration it would not be right to hide
that information.  We should not try to trick our users into sending
us something they did not want to send.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: please review bug #13141

[Glenn Morris]

If any of you corresponding on this want something useful to do, there
are hundreds (literally) of more important bugs currently open.

If you prefer to keep chatting, could you please at least confine it to
one mailing list?

RE: please review bug #13141

[Drew Adams]

>     I've had at least half a dozen cases
>     where users deleted automatically added information which I then
>     requested -- to no avail, since the reporters never responded.
> 
> To go out of their way to delete it makes me wonder why.  Maybe it was
> a valid reason.  Could it be that there was something private in that
> information which they specifically did not want to send?
> 
> Because of this consideration it would not be right to hide
> that information.  We should not try to trick our users into sending
> us something they did not want to send.

That is one valid reason a user might not want to send some information.

And a valid reason for Emacs not to hide it.  And a good reason to give users an
easy way to (a) not include it by default but also perhaps (b) be able to add
any piece of it by hitting a key.

Some have pointed out that the default set of info to include is one thing,
whether hard-coded or user customizable, but it is also the case that one often
wants to tailor the info sent to the particular bug.

A user who reports many bugs for which most of the default info is not pertinent
(just noise) can customize the option to get a different default set, as an
alternative to deleting the noise manually each time.

But it would be good to also let that user add this or that info quickly, when
relevant.  That is where (b) can come in (suggested by Dmitry).  The patch I
sent does not provide (b).  But it should be simple to do that.

Re: bug#13141: please review bug #13141

[Dmitry Gutov]

Richard Stallman <rms@gnu.org> writes:

> Stephen J. Turnbull writes:
>
>     I've had at least half a dozen cases
>     where users deleted automatically added information which I then
>     requested -- to no avail, since the reporters never responded.

If there's no information at all, maybe the users didn't go through the
Emacs bug reporting interface, writing the report directly in the email client.

> To go out of their way to delete it makes me wonder why.  Maybe it was
> a valid reason.  Could it be that there was something private in that
> information which they specifically did not want to send?

I usually delete most of it, because the default text looks messy, and I
don't like sending emails that look untidy. Also, it's harder to find
the actual report description if it's surrounded by auto-generated text.

It's better now that some parts of it are just shown through the display
property, but the user might not know/understand that.

> Because of this consideration it would not be right to hide
> that information.  We should not try to trick our users into sending
> us something they did not want to send.

As it is, the exact information the user's sending is not immediately
obvious, they'd have to carefully scroll though a fairly large chunk of
text to know that.

IMO, it would be better to ask about each potentially-sensitive section
(last keystrokes, obviously; local paths, recent messages? maybe), and
then include them as attachment or several.

Re: please review bug #13141

[Stephen J. Turnbull]

Richard Stallman writes:
 >     I've had at least half a dozen cases
 >     where users deleted automatically added information which I then
 >     requested -- to no avail, since the reporters never responded.
 > 
 > To go out of their way to delete it makes me wonder why.  Maybe it was
 > a valid reason.  Could it be that there was something private in that
 > information which they specifically did not want to send?

Some of it, yes, such as the keystroke log.  The list of shadowed
libraries would only very rarely be considered sensitive.  (For
example, if the user had modified a corporate internal library and was
shadowing it in her load-path.)

The cases of deletion I'm referring to were done with a chainsaw
rather than a scalpel.  I've always assumed the motive was a misguided
attempt to either localize the information to what they user thought
was a bug or to save bandwidth, but you could be right: they were
worried about the possibility of sensitive information leaking, and
chose to deal with the issue brutally.

 > Because of this consideration it would not be right to hide that
 > information.  We should not try to trick our users into sending us
 > something they did not want to send.

Agreed.  I withdraw the suggestion of appending the information after
the user hits "send".  Of course attaching it via MIME etc would be
not be the default (my phrasing is at fault here, I was writing from
the point of view of appeasing Drew and Fuqiao).

Re: please review bug #13141

[Stephen J. Turnbull]

Glenn Morris writes:

 > If any of you corresponding on this want something useful to do, there
 > are hundreds (literally) of more important bugs currently open.
 > 
 > If you prefer to keep chatting, could you please at least confine it to
 > one mailing list?

It's OK if you're annoyed, but please step down the sarcasm.  It has a
perverse effect, since we disagree with your opinion of what's useful.

A suggestion: you could add a feature to debbugs such that if any of a
list of mailing list addresses appears among the addressees, a message
is sent to the author asking for confirmation that they want to spam
both lists.  This would require users to do something positive to
actually send mail to a bug, and might even teach some of them to
delete bug addresses before sending.

Alternatively, you could teach your MUA to refuse to display
duplicates.

Re: bug#13141: please review bug #13141

[Stephen J. Turnbull]

Dmitry Gutov writes:
 > Richard Stallman <rms@gnu.org> writes:
 > > Stephen J. Turnbull writes:

 > >     I've had at least half a dozen cases where users deleted
 > >     automatically added information which I then requested -- to
 > >     no avail, since the reporters never responded.

 > If there's no information at all,

That's not the case.

Another suggestion, especially for the tidy reporter: a special minor
mode for editing and viewing bug reports with commands to skip to
specific sections of generated data and to reduce the amount of screen
space they occupy (a la outline mode, or perhaps the "MIME buttons"
displayed by Gnus and VM).

Re: bug#13141: please review bug #13141

[Stephen J. Turnbull]

Not Ccing <13141@debbugs.gnu.org> per Glenn's request.

Dmitry Gutov writes:

 > I usually delete most of it, because the default text looks messy, and I
 > don't like sending emails that look untidy. Also, it's harder to find
 > the actual report description if it's surrounded by auto-generated text.

Ah, I forgot about that.  Steve Youngs fixed that for us ages ago.
M-x report-xemacs-bug now pops up *two* buffers.  One is a mail
composition buffer which looks like this for message mode users:

------------------------------------------------------------------------
    To: XEmacs Beta <xemacs-beta@xemacs.org>
    Subject: [Bug: 21.5-b32] Nothing works in the latest beta
    --text follows this line--
    ================================================================
    Dear Bug Team!



    ================================================================

    System Info to help track down your bug:
    ---------------------------------------

------------------------------------------------------------------------

followed by the generated information.  The other buffer is a help
buffer explaining good style and desired content for bug reports,
appended below in full just in case it has useful ideas.  (Of course
it is tainted from a legal viewpoint, but it wouldn't be hard to
rewrite in a more GNU-y style.)  The help buffer can be manipulated
with the usual commands for such buffers, or suppressed completely.

Steve

------------------------------------------------------------------------
This bug report will be sent to the XEmacs Development Team,
not to your local site managers!!

The working language of XEmacs development is English.  Bug reports in
English will be dealt with most promptly and most effectively.  However, the
XEmacs maintainers as a group speak most of the major Western languages and
Japanese, so if communicating in English is a problem for you, please feel
free to report your bug using one of those other languages.

Please describe as succinctly as possible:
	- What happened.
	- What you thought should have happened.
	- Precisely what you were doing at the time.

Also include a reliable recipe for triggering the bug, as well as
any C and lisp back-traces that you may have.
(setq stack-trace-on-error t), or (setq debug-on-error t) if you
are familiar with the debugger, to get a lisp back-trace.
To get a core file for the C back-trace on a GNU/Linux system do 
'ulimit -c unlimited' in the shell prior to starting XEmacs.

Type C-c tab to visit in Info the XEmacs Manual section
about when and how to write a bug report,
and what information to supply so that the bug can be fixed.
Type SPC to scroll through this section and its subsections.

You are very welcome to scan through the bug report and remove any
potentially sensitive data.

Turn off this help buffer permanently by adding:

	 (setq report-xemacs-bug-no-explanations t)

To your ~/.xemacs/init.el

RE: please review bug #13141

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2165 bytes --]

> http://www.emacswiki.org/emacs-en/emacsbug%2b.el
>
> And I agree with Dmitry's additional suggestion that we could 
> provide a command or commands to insert individual information
> items, e.g., the same items a user can choose for the default
> behavior using the option:
> 
> * version info
> * important settings list
> * major mode
> * minor modes
> * recent input
> * recent messages
> * load-path shadows
> * features

I've done that now in the standalone version at the URL above.  The help buffer
describes the available keys (commands) for inserting info.  All such keys are
on prefix C-o.

Only those keys corresponding to info that is not automatically inserted,
according to the option value, are bound to keys.  And the help lists only those
that are currently bound.

E.g., if a user customizes the option to include no info by default, then a
command is bound for each info type, and all of those keys are listed in the
help, as shown in the attached screenshot.  When no info is inserted by default,
there is also a command/key to insert everything.

At the other extreme, by default everything is inserted automatically, so no
insertion commands are bound to keys and nothing is said in the help about the
commands.  The help is the same as in vanilla Emacs today, in that case, except
that it mentions the option that you can customize, with a link for that.

In between these extremes, the help shows keys for any info that did not get
inserted automatically.  It is very easy to add any type of info.

It's hard for me to believe that some people are still suggesting we require
users to answer a guantlet of questions about what info they want to provide.
That is so barbaric it makes my head spin.

This is the right approach, IMO:

Pick a good set of default info types to insert automatically (e.g., all of
them, today).  Then tell users, in the displayed help, that they can customize
an option to not include, by default, any of the info types they want.  If they
have customized that option to not include some types of info, then mention, in
the help, the keys that insert that missing info.

What could be simpler and more flexible?

[-- Attachment #2: throw-emacsbug-help.png --]
[-- Type: image/png, Size: 34408 bytes --]

[-- Attachment #3: throw-emacsbug-help-default.png --]
[-- Type: image/png, Size: 25336 bytes --]

RE: please review bug #13141

[Andrey Paramonov]

Maybe I'm missing something, but how customization would make any 
difference, given that users are always suggested to try 
reproduce/report bugs with emacs -Q ???

Best wishes,
Andrey Paramonov

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

RE: please review bug #13141

[Drew Adams]

> Maybe I'm missing something, but how customization would make any 
> difference, given that users are always suggested to try 
> reproduce/report bugs with emacs -Q ???

Good question.

Yes, what's requested is a recipe that starts from emacs -Q.

That doesn't mean that the emacs session where you submit the report must be an
emacs -Q session.  And some bug reports do not require a recipe from emacs -Q,
though that's always a good idea.

Re: please review bug #13141

[Harald Hanche-Olsen]

[Drew Adams <drew.adams@oracle.com> (2013-01-21 15:05:12 UTC)]

> That doesn't mean that the emacs session where you submit the report
> must be an emacs -Q session. And some bug reports do not require a
> recipe from emacs -Q, though that's always a good idea.

I don't know about others, but I can't possibly send email from an
emacs -Q session without going through a lot of trouble. Which means
recent input and messages are almost always irrelevant. It might make
sense to only include this data provided
(y-or-n-p "Did you encounter the bug just now in this emacs session?")

- Harald

Re: please review bug #13141

[Eli Zaretskii]

> Date: Mon, 21 Jan 2013 16:26:53 +0100 (CET)
> From: Harald Hanche-Olsen <hanche@math.ntnu.no>
> 
> I don't know about others, but I can't possibly send email from an
> emacs -Q session without going through a lot of trouble. Which means
> recent input and messages are almost always irrelevant.

You can always invoke "M-x report-emacs-bug RET" from "emacs -Q", then
copy the report with all the data it collected to another Emacs
session, and send it.

RE: please review bug #13141

[Drew Adams]

> > That doesn't mean that the emacs session where you submit the report
> > must be an emacs -Q session. And some bug reports do not require a
> > recipe from emacs -Q, though that's always a good idea.
> 
> I don't know about others, but I can't possibly send email from an
> emacs -Q session without going through a lot of trouble.

Yes.  It can be easier to just copy the composed report text from Emacs to an
external mail client.  Simple.  Trivial.  (And not clearly stated to users,
AFAICT.)

Configuring Emacs to send mail is understandably non-trivial.  The good news is
that one _need not_ use Emacs to send mail, including a bug report, provided one
has an external mail client.  (Users deserve to hear that good news.)

> Which means recent input and messages are almost always irrelevant.

No, not necessarily.  You can copy them to a different Emacs session where you
report the bug, if you like.

They are irrelevant only if in fact they are irrelevant to the particular bug
report at hand.  You, the reporter, are the immediate judge of that.  If you
think that that info is in fact irrelevant, then don't bother to include it in
your report.

If you think it is relevant, you can always copy it to another Emacs session
where mail is configured, or copy it to an external mail client, if you have
one.

> It might make sense to only include this data provided
> (y-or-n-p "Did you encounter the bug just now in this emacs session?")

Emacs (and Emacs Dev) should not try to be so clever.  It should not get fixated
on its automatic capturing of session information.

Just let users use their own judgment and act accordingly.  But let's give them
the means to do so easily.

Emacs should not try to second-guess users.  In general, it should avoid
interrogating them unnecessarily.  Let them act as they like, with reasonable
tools that help them get the job done.

At bottom, the user is just sending an email to bug-gnu-emacs@gnu.org - nothing
more.  Sheesh, not a big deal.  All `report-emacs-bug' is for is to help you do
that.  It is only a convenience command.

That Emacs pops up a buffer for you to compose the report text is the main
convenience.  That Emacs can address and later send the completed mail message,
using a mail client that is either integrated with Emacs or external to it, is
another convenience.  That Emacs can fill the report composition buffer with
some automatically captured info about the current session is yet another
convenience.

These are all (relatively minor) conveniences - nothing more.  The real, and
trivial, message can be lost in all of this:

 Report bugs to bug-gnu-emacs@gnu.org.

Our current user interrogation, before mail has been configured, is unfortunate.
IF configuration is to be done, then Emacs needs the answers, of course.  In
that case ONLY do we need to call in the Grand Inquisitor, so why start users
out with him?

Configuration is _not needed_ to send a bug report, if you have an external mail
client, which is true of most people nowadays.  That should be the default, the
starting point in our instructions to users.  Start with the simple method, and
make clear that the complex method is optional.

The first (and hence potentially the only) question the dialog should ask is
simply whether you want to use Emacs itself to send the mail.

But even for that there is no necessary reason to ask the user.  The
`report-emacs-bug' instructions should simply say:

 After composing your report here, copy it to a new mail message
 in your mail client, and send it to bug-gnu-emacs@gnu.org.

Instead, they dive immediately into saying that Emacs WILL send a mail, etc.

The instructions could continue by saying that IF you prefer instead that Emacs
send the mail for you, then hit `C-c C-c', which will lead you through the
necessary steps to send it.

IOW, there is no absolute need for Emacs to ever ask anything, in order for a
user to send a bug report.  Emacs should keep it simple, to start with.  The
complexity is optional, and it should be presented as such, AFTER telling users
they can just send an email to bug-gnu-emacs@gnu.org.

The bug reporting process has gotten out of hand, IMHO, because:

1. We like to provide convenience aids, and Emacs is good for composing text and
can easily retrieve info about the session.

2. Emacs Dev is proud of the fact that Emacs can itself be used as a mail
client, so it has warped the reporting procedure/dialog into one about sending
mail using Emacs.

It's all well and good to have Emacs _be able_ to help users compose their
report and send it.  But that possibility should not be taken as a necessity, or
end up as a restriction on the user.

Write, copy, paste, and send (from an external client) should at least be
MENTIONED, front and center, in the instructions/help shown by
`report-emacs-bug' as a primary way of reporting a bug.  Today, it is not.

Re: please review bug #13141

[Xue Fuqiao]

On Mon, 21 Jan 2013 14:20:31 -0800
"Drew Adams" <drew.adams@oracle.com> wrote:

> Configuration is _not needed_ to send a bug report, if you have an external mail
> client, which is true of most people nowadays.  That should be the default, the
> starting point in our instructions to users.  Start with the simple method, and
> make clear that the complex method is optional.

IIRC the default value of `send-mail-function' is `sendmail-query-once', which queries for `send-mail-function' and sends mail with the queried result (and also saves the value of `send-mail-function' via Customize).  And in the *Bug Help* buffer:

  Type C-c m to copy text to your preferred mail program.

> The first (and hence potentially the only) question the dialog should ask is
> simply whether you want to use Emacs itself to send the mail.
> 
> But even for that there is no necessary reason to ask the user.

I don't think so, it can be like this:

  Type C-c C-c to send the bug report (using send-mail-function).
-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

RE: please review bug #13141

[Drew Adams]

> > Configuration is _not needed_ to send a bug report, if you 
> > have an external mail client, which is true of most people
> > nowadays.  That should be the default, the starting point
> > in our instructions to users.  Start with the simple
> > method, and make clear that the complex method is optional.
> 
> IIRC the default value of `send-mail-function' is 
> `sendmail-query-once', which queries for `send-mail-function' 
> and sends mail with the queried result (and also saves the 
> value of `send-mail-function' via Customize).  And in the 
> *Bug Help* buffer:
>   Type C-c m to copy text to your preferred mail program.

And all of that complexity, which admittedly can lead to convenience, is extra,
unnecessary.  It can be nice, but it is not necessary in order for a user to
report a bug.  That's the point, and it is a point that is not passed along
clearly to users, IMO.

Users do not _need_ to bother with `send-mail-function', `sendmail-query-once',
automatic saving of customized values, or any of the rest.  They can just send
an email to bug-gnu-emacs@gnu.org, ignoring all of the Emacs paraphernalia
provided to assist you in doing that.

> > The first (and hence potentially the only) question the 
> > dialog should ask is simply whether you want to use Emacs
> > itself to send the mail.  But even for that there is no
> > necessary reason to ask the user.
> 
> I don't think so, it can be like this:
>   Type C-c C-c to send the bug report (using send-mail-function).

Sorry, I don't get your point.

My point was that we need not query the user _at all_, not even once.  Why?
Because s?he can just send a mail outside Emacs - QED.

The questioning and related hoopla is only for the case where the user wants to
either (a) have Emacs pull up his external mail client for him or (b) have Emacs
actually mail the message.

We have made that more complicated case into the default, regular case.  And we
neglect to simply mention the simpler case at all: just send an email to
bug-gnu-emacs@gnu.org.  (We mention that possibility in the manual, but not in
the `report-emacs-bug' instructions.)

If a user does not want to simply send a message using an external mail client,
perhaps after composing the message in Emacs and copying it, then s?he can hit
C-c C-c to get the behavior you describe (the querying, config dialog if
appropriate, etc.).  Otherwise, no questions needed.

But today the instructions displayed when you invoke `report-emacs-bug' do not
even make it clear that you have the (simpler) option of just sending a message
to bug-gnu-emacs@gnu.org.  We immediately lead the user down the garden path of
our helpful inquisition.  That's not necessary.

It's great to provide the conveniences we do, to help users get their reports to
Emacs Dev.  But it's not _necessary_ for users to do things that way.

The convenience we provide is a nice-to-have, and it should be kept, of course.
But it should not be the first thing we tell users about, wrt reporting a bug.
The first thing to tell them is that all they need to do is send an email to
bug-gnu-emacs@gnu.org.

KISS.  See also http://en.wikipedia.org/wiki/Occam's_razor.

Re: please review bug #13141

[Xue Fuqiao]

On Mon, 21 Jan 2013 22:40:32 -0800
"Drew Adams" <drew.adams@oracle.com> wrote:

> Users do not _need_ to bother with `send-mail-function', `sendmail-query-once',
> automatic saving of customized values, or any of the rest.

Yes, they can just use C-c m to copy text to their preferred mail program.

> And we
> neglect to simply mention the simpler case at all: just send an email to
> bug-gnu-emacs@gnu.org.  (We mention that possibility in the manual, but not in
> the `report-emacs-bug' instructions.)

The instructions in `report-emacs-bug' are:

Type C-c TAB to visit in Info the Emacs Manual section about when and how to write a bug report, and what information you should include to help fix the bug.

I think many users (including new users) will see the Info, although some of them will not read it from the beginning to the end.

-- 
Best regards, Xue Fuqiao.
http://www.emacswiki.org/emacs/XueFuqiao

RE: please review bug #13141

[Drew Adams]

> > Users do not _need_ to bother with `send-mail-function', 
> > `sendmail-query-once', automatic saving of customized values,
> > or any of the rest.
> 
> Yes, they can just use C-c m to copy text to their preferred 
> mail program.

The point is that the `report-emacs-bug' instructions do not even mention
bug-gnu-emacs@gnu.org.

That is the most important piece of info for the instructions to mention.  It is
the ultimate aim of `report-emacs-bug'.  The address is even more important than
the guidelines about what information to send.

> > And we neglect to simply mention the simpler case at all:
> > just send an email to bug-gnu-emacs@gnu.org.  (We mention that
> > possibility in the manual, but not in the `report-emacs-bug'
> > instructions.)
> 
> The instructions in `report-emacs-bug' are:...

I'm aware that the instructions have a cross ref to the manual.  That's not the
same thing as the instructions telling users they can just send an email to
bug-gnu-emacs@gnu.org.

> I think many users (including new users) will see the Info, 
> although some of them will not read it from the beginning to the end.

And even in the manual we do not communicate the message very clearly.  We first
tell them to use C-c C-c and Emacs will send the report to
`bug-gnu-emacs@gnu.org'.  Only afterward do we tell them they can send mail
outside Emacs etc.

The presentation in the doc is FIRST in terms of `C-c C-c' plus automatic
sending and THEN, as a backup, `C-c m' plus mail client "(if your system
supports it...)".

This is backward.  We should start by saying clearly that all you have to do is
send an email to bug-gnu-emacs@gnu.org.  THEN we can mention `C-c m' "(if your
system supports it...)".  And THEN we can mention `C-c C-c' and the fact that
Emacs will do it all for you, provided it is configured for that.

BTW, the key `C-c m' was unwisely introduced in Emacs 24.1, presumably by
someone who has not read, or has forgotten, that this key is reserved for users.
Unfortunately, this bug was not caught in any review.  I filed bug #13510 for it
a few days ago.