Remove "Recent messages" from `M-x report-emacs-bug'

Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Emacs bug reports include the ten most recent lines from the *Messages*
buffer.  I think that's kinda unfortunate -- there may be private stuff
there that people are not expecting to share with the world.

And I've never found that data useful when doing bug triage.

Should we remove it from the report?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 10:15 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Emacs bug reports include the ten most recent lines from the *Messages*
> buffer.  I think that's kinda unfortunate -- there may be private stuff
> there that people are not expecting to share with the world.
>
+1

I also don't like sharing the IP.

The line:

In GNU Emacs 25.0.93.5 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2016-05-05 built on <IP>.

Is putting the IP there useful?


> And I've never found that data useful when doing bug triage.
>
> Should we remove it from the report?
>

I wouldn't mind that.

Would instead adding `view-lossage` dump help? That way we can see what
commands the user ran to recreate the bug before reporting it. Now
view-lossage also lists the commands corresponding to the bindings.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1441 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 10:20 AM Kaushal Modi <kaushal.modi@gmail.com> wrote:

> I also don't like sharing the IP.
>
> The line:
>
> In GNU Emacs 25.0.93.5 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
>  of 2016-05-05 built on <IP>.
>
> Is putting the IP there useful?
>

This can be ignored. I just added a short advice in my config to let bind
emacs-build-system around report-emacs-bug to solve this :)
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 990 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Andreas Schwab]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Would instead adding `view-lossage` dump help?

view-lossage is as confidential as the messages.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 09 May 2016 14:20:17 +0000
> 
> Would instead adding `view-lossage` dump help?

It was there once, but was removed not long ago for the same reasons
of privacy.

RE: Remove "Recent messages" from `M-x report-emacs-bug'

[Drew Adams]

> Emacs bug reports include the ten most recent lines from the *Messages*
> buffer.  I think that's kinda unfortunate -- there may be private stuff
> there that people are not expecting to share with the world.
> 
> And I've never found that data useful when doing bug triage.
> 
> Should we remove it from the report?

It should possible for a _user_ to easily decide this, and not
just for the most recent lines from *Messages*.

Users should be able choose the default behavior for themselves -
which types of info to automatically include when they use
`M-x report-emacs-bug'.

And if they choose to not include certain types of info by default
they should still be able to easily include it interactively, for
any given bug report.

Library `emacsbug+.el' offers this, with option
`ebp-report-emacs-bug-included-fields' and these commands:

 `ebp-insert-all', `ebp-insert-features',
 `ebp-insert-load-path-shadows', `ebp-insert-major-mode',
 `ebp-insert-minor-modes', `ebp-insert-recent-input',
 `ebp-insert-recent-messages', `ebp-insert-settings',
 `ebp-insert-version'.

The default value of the option includes all of the fields:

  (version settings major-mode minor-modes recent-input
   recent-messages load-shadows features)

https://www.emacswiki.org/emacs/download/emacsbug%2b.el

So to satisfy only your concern, a user would only need to
remove `recent-messages' from the option value.  If your
suggestion of removing it by default were taken, then it
would just be removed from the default value of the option.

FWIW, I suggested such a user-control feature for vanilla
Emacs, but it was rejected.  See this (long) emacs-devel
thread:

http://lists.gnu.org/archive/html/emacs-devel/2013-01/msg00431.html

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It should possible for a _user_ to easily decide this, and not
  > just for the most recent lines from *Messages*.

  > Users should be able choose the default behavior for themselves -

Maybe it would be more useful to ask this question each time
the user runs report-emacs-bug.

It could ask, "Should Emacs insert information on your recent editing
into the bug report?  (If you say yes, you will be able to delete any
parts of that text from the mail buffer.)"  If the user says yes to
this, it should insert all the data we would find useful.  If no, then
none of it.

This should be enough to protect the user anyone from leaking anything private.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 09 May 2016 15:53:19 +0200
> 
> Emacs bug reports include the ten most recent lines from the *Messages*
> buffer.  I think that's kinda unfortunate -- there may be private stuff
> there that people are not expecting to share with the world.
> 
> And I've never found that data useful when doing bug triage.
> 
> Should we remove it from the report?

Please don't.  We already removed too much valuable stuff from the
report, and that definitely hampers debugging remote problems.  It is
okay to let users opt-out by removing portions of the report, if they
want that, but if we continue removing important portions of the
report, we might as well delete the command altogether, because it
becomes less and less useful; soon enough a simple unformatted mail
message will provide the same info (or lack thereof) as this command.

In case it wasn't clear, I object strenuously to unconditional removal
of that info as the default behavior.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> In case it wasn't clear, I object strenuously to unconditional removal
> of that info as the default behavior.

Your opinion here is, of course, very important -- you are the one that
handles most of the bug reports.

But I'm wondering why our experiences here are so different.  I don't
think I've ever found those messages important for handling a bug
report.  I mean, ever.  Do you often find that those messages are
important for tracking down bugs?

The few times I've even glanced at them, they've have mostly been about
something completely irrelevant -- what the user had been doing while
trying to figure out how to file the bug report, and not about what had
happened when the bug happened.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 09 May 2016 20:25:39 +0200
> 
> But I'm wondering why our experiences here are so different.  I don't
> think I've ever found those messages important for handling a bug
> report.  I mean, ever.  Do you often find that those messages are
> important for tracking down bugs?

Yes, definitely.  Users seldom tell enough details about what they see
or do, and the information collected by report-emacs-bug, including
the *Messages* part, sometimes provides clues that it would be very
hard to get at otherwise.  Especially when the bug is not easily
reproducible, or there's no recipe at all.  The alternative is to
start asking tedious questions about what they did and what Emacs
displayed, deal with incomplete and inaccurate accounts of that, etc.

> The few times I've even glanced at them, they've have mostly been about
> something completely irrelevant -- what the user had been doing while
> trying to figure out how to file the bug report, and not about what had
> happened when the bug happened.

That happens quite a lot, yes.  But disregarding irrelevant data is
easy enough.  When the data _is_ relevant it is invaluable, so even if
it happens infrequently, losing it would be a bad blow.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> That happens quite a lot, yes.  But disregarding irrelevant data is
> easy enough.  When the data _is_ relevant it is invaluable, so even if
> it happens infrequently, losing it would be a bad blow.

Right.  What about moving the messages earlier so that the users notice
that they're there?

Today the order is build/configured features/important settings/minor
modes and then Recent messages.  That's so far down that I think most
people won't notice that they're there.  How about moving it up to under
the build info?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Dmitry Gutov]

On 05/09/2016 10:13 PM, Lars Ingebrigtsen wrote:

> Right.  What about moving the messages earlier so that the users notice
> that they're there?

I think most of that information should be moved to attached files (so 
we don't waste the time scrolling bug reports every time, at least in 
the debbugs web interface).

And it wouldn't hurt if it was easier to remove the unintended pieces of 
information than mark->end-of-buffer->kill.

It gets tedious, and I have to watch out to not remove everything.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

>> Right.  What about moving the messages earlier so that the users notice
>> that they're there?
>
> I think most of that information should be moved to attached files (so
> we don't waste the time scrolling bug reports every time, at least in
> the debbugs web interface).

Sure, but that's kinda orthogonal.  To make it an attachment we just
have to put the <part disposition=attachment> before the text we want to
become an attachment.  It doesn't affect how we arrange the text inside
the attachment.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 09 May 2016 21:25:18 +0200
> 
> To make it an attachment we just have to put the <part
> disposition=attachment> before the text we want to become an
> attachment.

Actually, it's much trickier than that: report-emacs-bug supports
several possible mail clients, including the lowest-tech way of
passing the message through the clipboard, so you could paste it into
your system mailer.  How do you arrange for attachments then?

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, it's much trickier than that: report-emacs-bug supports
> several possible mail clients, including the lowest-tech way of
> passing the message through the clipboard, so you could paste it into
> your system mailer.  How do you arrange for attachments then?

Well, it doesn't work for the people who paste.  But it should work for
all the other transports...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Actually, it's much trickier than that: report-emacs-bug supports
>> several possible mail clients, including the lowest-tech way of
>> passing the message through the clipboard, so you could paste it into
>> your system mailer.  How do you arrange for attachments then?
>
> Well, it doesn't work for the people who paste.  But it should work for
> all the other transports...

And see my related post about submitting the bug reports directly to
debbugs.gnu.org, which should work for most people.

Glenn, is there a chance of getting the debbugs.gnu.org Exim
installation to listen to port 587 (mail submission) in addition to port
25?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Glenn Morris]

Lars Ingebrigtsen wrote:

> Glenn, is there a chance of getting the debbugs.gnu.org Exim
> installation to listen to port 587 (mail submission) in addition to port
> 25?

(As a reminder, please ask debbugs qs on help-debbugs.)
I guess it's possible. But:

1) Are there security implications? Will I get more spam?

2) By itself, AFAICS it won't do anything, since bug reports go to
bug-gnu-emacs@gnu.org. Are you proposing to change this to
submit@debbugs? I'm not sure this is a good idea; eg it will make life
harder when y'all want to switch to the next bug tracker (it will no
longer be possible to just redirect bug-gnu-emacs to the new system).

3) Do you really think we are missing a significant number of reports
because "send an email" is too difficult? (We aren't capable of fixing
all the existing reports anyway.) Is "if you can't send this directly,
just copy and paste to your preferred mail client" that hard?


(Perhaps debbugs would benefit from a new maintainer, because these days
I seem to just say no to things.)

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 3:18 PM Dmitry Gutov <dgutov@yandex.ru> wrote:

> I think most of that information should be moved to attached files (so
> we don't waste the time scrolling bug reports every time, at least in
> the debbugs web interface).


Please, no. Making those as attachments will totally break the flow that I
and few? others use to send the bug reports.

I create the report in emacs, C-x h M-w and then paste that in Gmail to
send out the email. I go through that inconvenience because I cannot send
out emails from my emacs machine (more detail: I copy the text from emacs
running in linux on a VNC server into windows to email via Gmail). If now
part of the email is attachment, moving the attachment too via the VNC
would become very inconvenient.

This idea might be getting out of hand.. but how about have the body in
org/outline format? Then we can conveniently collapse sections, mark
sections to copy/delete, etc.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1318 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Please, no. Making those as attachments will totally break the flow that I and
> few? others use to send the bug reports.

No, it won't.  It would just add a <part> line to the text.

> I create the report in emacs, C-x h M-w and then paste that in Gmail to send
> out the email. I go through that inconvenience because I cannot send out
> emails from my emacs machine (more detail: I copy the text from emacs
> running in linux on a VNC server into windows to email via Gmail).

Are ports 25 and 587 blocked?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 3:37 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Kaushal Modi <kaushal.modi@gmail.com> writes:
> No, it won't.  It would just add a <part> line to the text.
>

OK. Thanks. Then that would be fine.

Are ports 25 and 587 blocked?


Hmm, now that I think.. I married two issues together.. I have never been
able to configure gnus to work.. it just times out when trying to fetch
even news,gmane.org and also I was never able to setup gmail using that
(same timeout issue). Secondly I cannot send bug reports from within emacs
as the outgoing email will be my work email (instead of the gmail email
where I subscribe to all emacs ML). I have verified sendmail to work
before. But I cannot use it as I cannot associate it with my gmail account.
Sorry for that long answer but I don't know if ports 25 and 587 have
anything to do with report-emacs-bug. But it probably has to do with my
gnus issue.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Hmm, now that I think.. I married two issues together.. I have never been
> able to configure gnus to work.. it just times out when trying to fetch even
> news,gmane.org and also I was never able to setup gmail using that (same
> timeout issue).

Reading mail and sending mail are two totally different things that have
nothing do to with one another.

> Secondly I cannot send bug reports from within emacs as the
> outgoing email will be my work email (instead of the gmail email where I
> subscribe to all emacs ML). I have verified sendmail to work before. But I
> cannot use it as I cannot associate it with my gmail account.

You don't need sendmail or anything like that.  When you try to send
mail from an Emacs that doesn't have outgoing mail set up, it will
prompt you for how to send email.  Say "smtp.gmail.com", and you're
set.  (You may have to enter a password at some point, though.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 3:58 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> You don't need sendmail or anything like that.  When you try to send
> mail from an Emacs that doesn't have outgoing mail set up, it will
> prompt you for how to send email.  Say "smtp.gmail.com", and you're
> set.  (You may have to enter a password at some point, though.)


Thanks. But that also didn't help (I just tried). Ports 25, 465 are blocked.

Doing "telnet smtp.gmail.com 25" or "telnet smtp.gmail.com 465" gives me
connection timeout.

You also mentioned that the attachment methods will not work for people who
paste. I am essentially copying the mail content from the emacs report
bug/compose mail buffer in linux and then pasting it across VNC in
Gmail/Inbox compose window in Windows. So all data that I copy has to be
plain text (no meta data like what we get when we copy stuff from a web
browser).
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Thanks. But that also didn't help (I just tried). Ports 25, 465 are blocked.

Port 587 is the mail submit port.

> You also mentioned that the attachment methods will not work for people
> who paste. I am essentially copying the mail content from the emacs report
> bug/compose mail buffer in linux and then pasting it across VNC in
> Gmail/Inbox compose window in Windows. So all data that I copy has to be
> plain text (no meta data like what we get when we copy stuff from a web
> browser).

There is nothing but plain text to copy, even when a Message buffer is
set up for doing attachments.  You won't be sending attachments if you
do copy, but that's not any worse than the situation is today.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Kaushal Modi]

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

On Mon, May 9, 2016 at 4:56 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Port 587 is the mail submit port.
>

Yup, tried that too but doesn't work for me.

Tried regular telnet, didn't work. Also tried the below from
http://stackoverflow.com/a/11049483/1219634 and that too did not work.

openssl s_client -starttls smtp -connect smtp.gmail.com:587 -crlf -ign_eof

or

openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof

I will just live with copying mail body in emacs and sending it via Gmail.
I have spent a lot of time trying to make this work in the past and it just
doesn't work based on all the blocked ports (sendmail works but only for
sending mails in the company internally).


> There is nothing but plain text to copy, even when a Message buffer is
> set up for doing attachments.  You won't be sending attachments if you
> do copy, but that's not any worse than the situation is today.
>

OK.
-- 

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 1693 bytes --]

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Rasmus]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Hmm, now that I think.. I married two issues together.. I have never been
> able to configure gnus to work.. it just times out when trying to fetch
> even news,gmane.org and also I was never able to setup gmail using that
> (same timeout issue).

Maybe the port is blocked?  I think gmane supports several ports.
According to my init.el, I have had good results with 563.

(add-to-list 'gnus-secondary-select-methods
               '(nntp "gmane"
                      (nntp-address "news.gmane.org")
                      (nntp-connection-timeout 5)
                      (nntp-open-connection-function nntp-open-ssl-stream)
                      (nntp-port-number 563)))

> Secondly I cannot send bug reports from within emacs
> as the outgoing email will be my work email (instead of the gmail email
> where I subscribe to all emacs ML).

For me, it is sufficient to set the X-Message-Smtp-Method header,

   http://www.gnu.org/software/emacs/manual/html_node/message/Mail-Variables.html

-- 
... The proofs are technical in nature and provide no real understanding

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Nicolas Richard]

Dmitry Gutov <dgutov@yandex.ru> writes:
> of information than mark->end-of-buffer->kill.

FWIW, end-of-buffer already sets the mark for you so you can do <C-end>
C-w or M-> C-w

-- 
Nicolas Richard

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 09 May 2016 21:13:49 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That happens quite a lot, yes.  But disregarding irrelevant data is
> > easy enough.  When the data _is_ relevant it is invaluable, so even if
> > it happens infrequently, losing it would be a bad blow.
> 
> Right.  What about moving the messages earlier so that the users notice
> that they're there?

No objections here.

> Today the order is build/configured features/important settings/minor
> modes and then Recent messages.  That's so far down that I think most
> people won't notice that they're there.  How about moving it up to under
> the build info?

I don't mind.

Thanks.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Right.  What about moving the messages earlier so that the users notice
>> that they're there?
>
> No objections here.

Ok; I've now done this on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: Remove "Recent messages" from `M-x report-emacs-bug'

[Drew Adams]

> >> Right.  What about moving the messages earlier so that the
> >> users notice that they're there?
> >
> > No objections here.
> 
> Ok; I've now done this on the trunk.

This is crazy, IMHO.

I really do not understand why you are now entertaining
complex, convoluted, and ugly (IMO) "solutions" to this
problem.

You are envisaging all kinds of things: changing the report
format, changing how bug reports are sent, the UI,...

Talk about overreaction!  Lars brings up something that annoys
him and suddenly the Emacs code is changed to adjust to his
annoyance (and in a weird way).

Why don't you just adopt what I suggested (emacsbugs+.el or
similar)?  The relevant changes to emacsbug.el are tiny and
trivial.  With the default option value, users see no change
whatsoever.  But you could change the default option value
so that `report-messages' (or whatever) would not be included.

Among other things, it would make the emacsbug.el code a bit
more modular - it just breaks up the info that is scooped up
into pieces/categories, and makes it easy to include/exclude
the pieces.

It means no changes to the existing bug-report format.  It just
gives users an easy way to determine just what information they
send with a bug report - both in general (their preferred default
behavior) and on the fly, for any given bug report.

If you do decide to do what emacsbug+.el does I will gladly
send it as a patch.  It is just a small extension to the code
in emacsbug.el.  But why don't you just try it first?

https://www.emacswiki.org/emacs/download/emacsbug%2b.el

--

And if you continue to ignore this, then allow me to at least
voice my objection to moving ANY of the data gathered BEFORE
the user-typed bug report itself.  That's nuts, IMHO.  Keep
the report at the top, and the supporting/background data at
the bottom.  Just one opinion.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Should we remove it from the report?

+1

That's one of the reasons why I always write my bug reports on a freshly
created emacs session. Or just remove all the auto-included text
from the report, except for the version string.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Paul Eggert]

On 05/09/2016 10:32 AM, Óscar Fuentes wrote:
> I always write my bug reports on a freshly
> created emacs session. Or just remove all the auto-included text
> from the report, except for the version string.
>
>

I also typically avoid report-emacs-bug, for reasons of privacy. I do 
too many important things in Emacs to be blase about broadcasting its 
state to the public. I realize that it's sometimes important to mention 
private details as part of a bug report, but would prefer this to be 
opt-in and not opt-out as it is now.

RE: Remove "Recent messages" from `M-x report-emacs-bug'

[Drew Adams]

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > It should possible for a _user_ to easily decide this, and not
>   > just for the most recent lines from *Messages*.
> 
>   > Users should be able choose the default behavior for themselves -
> 
> Maybe it would be more useful to ask this question each time
> the user runs report-emacs-bug.
> 
> It could ask, "Should Emacs insert information on your recent editing
> into the bug report?  (If you say yes, you will be able to delete any
> parts of that text from the mail buffer.)"  If the user says yes to
> this, it should insert all the data we would find useful.  If no, then
> none of it.
> 
> This should be enough to protect the user anyone from leaking anything
> private.

Asking is not bad, as a default behavior.  But a user who is asked
should be able, while responding, to state whether s?he wants to
continue to be asked for subsequent bug reports.

Instead of all or none, present the user with the customize buffer,
to decide just which kinds of information to include by default.

It's not just about privacy, and it's not just about recent editing.
There can be other reasons why a user might not want to include (or
to bother with) different kinds of info.

1. It should be apparent to a user what info s?he is sending.
2. It should be up to the user to decide what s?he sends by default.
3. It should be easy (and obvious how) to change what gets sent for
   any given bug report - i.e., to do something different from what
   the user has chosen as preferred default behavior.
4. None of this should introduce inconvenience.  No bothersome
   questions each time you send a bug report, etc.
5. The bug report itself should be first, and any background,
   supporting information should follow, in the bug report.

In addition, I (too) think that everything sent should be in one
plain-text message, with no attachments (as now).  And I do not
think we should change the format (e.g. order of information)
gratuitously.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Asking is not bad, as a default behavior.  But a user who is asked
  > should be able, while responding, to state whether s?he wants to
  > continue to be asked for subsequent bug reports.

Why?  The answer won't be the same each time.  It depends on what
you're doing.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

RE: Remove "Recent messages" from `M-x report-emacs-bug'

[Drew Adams]

>   > Asking is not bad, as a default behavior.  But a user who is asked
>   > should be able, while responding, to state whether s?he wants to
>   > continue to be asked for subsequent bug reports.
> 
> Why?  The answer won't be the same each time.  It depends on what
> you're doing.

The answer _might_ be the same each time.  Or it might be the
same _most_ times.  The point is to give a user the chance to
_decide whether_ to be asked each time.  Some users might not
want to be asked each time.

A user can set personal default behavior.  A user can override
that behavior for any given bug report (e.g., if s?he thinks
that some kind of info is important to that report).

These latter two features are what I provided in the slight
extension to emacsbug.el: (1) Let users customize what the
default behavior is, for them. (2) Let users override this
for any given report, by providing commands that insert
particular kinds of info.

What you added to the mix was the suggestion to ask users
what they want to do in this regard, when they submit a
report.

What I added to your suggestion is to let users do that
AND let them choose whether to (a) apply their answer
also to future reports or (b) be asked anew each time.

Re: Remove "Recent messages" from `M-x report-emacs-bug'

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The answer _might_ be the same each time.  Or it might be the
  > same _most_ times.  The point is to give a user the chance to
  > _decide whether_ to be asked each time.  Some users might not
  > want to be asked each time.

How many times a day is a person likely to report an Emacs bug?  Is
there anyone who reports bugs at an average rate of even one bug per
day?  I doubt it.

Saving a person an unwanted question at such rare intervals is not
worth enough to matter.

The two things that do matter are

* Privacy.
* Reporting more of the possibly useful data.

The balance between these will vary, so it makes
sense to ask the user to judge it each time.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.