* RE: Remove "Recent messages" from `M-x report-emacs-bug' [not found] ` <<E1b09ty-0002sA-MS@fencepost.gnu.org> @ 2016-05-10 16:20 ` Drew Adams 2016-05-11 0:08 ` Richard Stallman [not found] ` <<3ad08202-3529-4613-8f78-ef10b3abb9e2@default> 1 sibling, 1 reply; 35+ messages in thread From: Drew Adams @ 2016-05-10 16:20 UTC (permalink / raw) To: rms; +Cc: larsi, emacs-devel > [[[ 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-10 16:20 ` Remove "Recent messages" from `M-x report-emacs-bug' Drew Adams @ 2016-05-11 0:08 ` Richard Stallman 0 siblings, 0 replies; 35+ messages in thread From: Richard Stallman @ 2016-05-11 0:08 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <<3ad08202-3529-4613-8f78-ef10b3abb9e2@default>]
[parent not found: <<E1b0HhP-0006Me-VF@fencepost.gnu.org>]
* RE: Remove "Recent messages" from `M-x report-emacs-bug' [not found] ` <<E1b0HhP-0006Me-VF@fencepost.gnu.org> @ 2016-05-11 14:44 ` Drew Adams 2016-05-12 0:23 ` Richard Stallman 0 siblings, 1 reply; 35+ messages in thread From: Drew Adams @ 2016-05-11 14:44 UTC (permalink / raw) To: rms, Drew Adams; +Cc: larsi, emacs-devel > > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-11 14:44 ` Drew Adams @ 2016-05-12 0:23 ` Richard Stallman 0 siblings, 0 replies; 35+ messages in thread From: Richard Stallman @ 2016-05-12 0:23 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, drew.adams, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Remove "Recent messages" from `M-x report-emacs-bug' @ 2016-05-09 13:53 Lars Ingebrigtsen 2016-05-09 14:20 ` Kaushal Modi ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 13:53 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 13:53 Lars Ingebrigtsen @ 2016-05-09 14:20 ` Kaushal Modi 2016-05-09 14:39 ` Kaushal Modi ` (2 more replies) 2016-05-09 14:44 ` Drew Adams ` (2 subsequent siblings) 3 siblings, 3 replies; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 14:20 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 14:20 ` Kaushal Modi @ 2016-05-09 14:39 ` Kaushal Modi 2016-05-09 14:46 ` Andreas Schwab 2016-05-09 16:34 ` Eli Zaretskii 2 siblings, 0 replies; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 14:39 UTC (permalink / raw) To: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 14:20 ` Kaushal Modi 2016-05-09 14:39 ` Kaushal Modi @ 2016-05-09 14:46 ` Andreas Schwab 2016-05-09 16:34 ` Eli Zaretskii 2 siblings, 0 replies; 35+ messages in thread From: Andreas Schwab @ 2016-05-09 14:46 UTC (permalink / raw) To: Kaushal Modi; +Cc: emacs-devel 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." ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 14:20 ` Kaushal Modi 2016-05-09 14:39 ` Kaushal Modi 2016-05-09 14:46 ` Andreas Schwab @ 2016-05-09 16:34 ` Eli Zaretskii 2 siblings, 0 replies; 35+ messages in thread From: Eli Zaretskii @ 2016-05-09 16:34 UTC (permalink / raw) To: Kaushal Modi; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 13:53 Lars Ingebrigtsen 2016-05-09 14:20 ` Kaushal Modi @ 2016-05-09 14:44 ` Drew Adams 2016-05-10 15:48 ` Richard Stallman 2016-05-09 16:31 ` Eli Zaretskii 2016-05-09 17:32 ` Óscar Fuentes 3 siblings, 1 reply; 35+ messages in thread From: Drew Adams @ 2016-05-09 14:44 UTC (permalink / raw) To: Lars Ingebrigtsen, emacs-devel > 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 14:44 ` Drew Adams @ 2016-05-10 15:48 ` Richard Stallman 0 siblings, 0 replies; 35+ messages in thread From: Richard Stallman @ 2016-05-10 15:48 UTC (permalink / raw) To: Drew Adams; +Cc: larsi, emacs-devel [[[ 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 13:53 Lars Ingebrigtsen 2016-05-09 14:20 ` Kaushal Modi 2016-05-09 14:44 ` Drew Adams @ 2016-05-09 16:31 ` Eli Zaretskii 2016-05-09 18:25 ` Lars Ingebrigtsen 2016-05-09 17:32 ` Óscar Fuentes 3 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2016-05-09 16:31 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 16:31 ` Eli Zaretskii @ 2016-05-09 18:25 ` Lars Ingebrigtsen 2016-05-09 19:09 ` Eli Zaretskii 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 18:25 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 18:25 ` Lars Ingebrigtsen @ 2016-05-09 19:09 ` Eli Zaretskii 2016-05-09 19:13 ` Lars Ingebrigtsen 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2016-05-09 19:09 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:09 ` Eli Zaretskii @ 2016-05-09 19:13 ` Lars Ingebrigtsen 2016-05-09 19:17 ` Dmitry Gutov 2016-05-09 19:40 ` Eli Zaretskii 0 siblings, 2 replies; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 19:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:13 ` Lars Ingebrigtsen @ 2016-05-09 19:17 ` Dmitry Gutov 2016-05-09 19:25 ` Lars Ingebrigtsen ` (2 more replies) 2016-05-09 19:40 ` Eli Zaretskii 1 sibling, 3 replies; 35+ messages in thread From: Dmitry Gutov @ 2016-05-09 19:17 UTC (permalink / raw) To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:17 ` Dmitry Gutov @ 2016-05-09 19:25 ` Lars Ingebrigtsen 2016-05-09 19:43 ` Eli Zaretskii 2016-05-09 19:34 ` Kaushal Modi 2016-05-10 12:32 ` Nicolas Richard 2 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 19:25 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:25 ` Lars Ingebrigtsen @ 2016-05-09 19:43 ` Eli Zaretskii 2016-05-09 19:55 ` Lars Ingebrigtsen 0 siblings, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2016-05-09 19:43 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel, dgutov > 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? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:43 ` Eli Zaretskii @ 2016-05-09 19:55 ` Lars Ingebrigtsen 2016-05-09 20:13 ` Lars Ingebrigtsen 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 19:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel, dgutov 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:55 ` Lars Ingebrigtsen @ 2016-05-09 20:13 ` Lars Ingebrigtsen 2016-05-10 22:37 ` Glenn Morris 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 20:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rgm, emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 20:13 ` Lars Ingebrigtsen @ 2016-05-10 22:37 ` Glenn Morris 0 siblings, 0 replies; 35+ messages in thread From: Glenn Morris @ 2016-05-10 22:37 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel 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.) ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:17 ` Dmitry Gutov 2016-05-09 19:25 ` Lars Ingebrigtsen @ 2016-05-09 19:34 ` Kaushal Modi 2016-05-09 19:37 ` Lars Ingebrigtsen 2016-05-10 12:32 ` Nicolas Richard 2 siblings, 1 reply; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 19:34 UTC (permalink / raw) To: Dmitry Gutov, Lars Ingebrigtsen, Eli Zaretskii; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:34 ` Kaushal Modi @ 2016-05-09 19:37 ` Lars Ingebrigtsen 2016-05-09 19:44 ` Kaushal Modi 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 19:37 UTC (permalink / raw) To: Kaushal Modi; +Cc: Eli Zaretskii, emacs-devel, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:37 ` Lars Ingebrigtsen @ 2016-05-09 19:44 ` Kaushal Modi 2016-05-09 19:58 ` Lars Ingebrigtsen 2016-05-10 10:06 ` Rasmus 0 siblings, 2 replies; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 19:44 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:44 ` Kaushal Modi @ 2016-05-09 19:58 ` Lars Ingebrigtsen 2016-05-09 20:23 ` Kaushal Modi 2016-05-10 10:06 ` Rasmus 1 sibling, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 19:58 UTC (permalink / raw) To: Kaushal Modi; +Cc: Eli Zaretskii, emacs-devel, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:58 ` Lars Ingebrigtsen @ 2016-05-09 20:23 ` Kaushal Modi 2016-05-09 20:56 ` Lars Ingebrigtsen 0 siblings, 1 reply; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 20:23 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel, Dmitry Gutov [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 20:23 ` Kaushal Modi @ 2016-05-09 20:56 ` Lars Ingebrigtsen 2016-05-09 21:03 ` Kaushal Modi 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 20:56 UTC (permalink / raw) To: Kaushal Modi; +Cc: Eli Zaretskii, Dmitry Gutov, emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 20:56 ` Lars Ingebrigtsen @ 2016-05-09 21:03 ` Kaushal Modi 0 siblings, 0 replies; 35+ messages in thread From: Kaushal Modi @ 2016-05-09 21:03 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, Dmitry Gutov, emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:44 ` Kaushal Modi 2016-05-09 19:58 ` Lars Ingebrigtsen @ 2016-05-10 10:06 ` Rasmus 1 sibling, 0 replies; 35+ messages in thread From: Rasmus @ 2016-05-10 10:06 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:17 ` Dmitry Gutov 2016-05-09 19:25 ` Lars Ingebrigtsen 2016-05-09 19:34 ` Kaushal Modi @ 2016-05-10 12:32 ` Nicolas Richard 2 siblings, 0 replies; 35+ messages in thread From: Nicolas Richard @ 2016-05-10 12:32 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:13 ` Lars Ingebrigtsen 2016-05-09 19:17 ` Dmitry Gutov @ 2016-05-09 19:40 ` Eli Zaretskii 2016-05-09 20:07 ` Lars Ingebrigtsen 1 sibling, 1 reply; 35+ messages in thread From: Eli Zaretskii @ 2016-05-09 19:40 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 19:40 ` Eli Zaretskii @ 2016-05-09 20:07 ` Lars Ingebrigtsen 2016-05-09 20:35 ` Drew Adams 0 siblings, 1 reply; 35+ messages in thread From: Lars Ingebrigtsen @ 2016-05-09 20:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* RE: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 20:07 ` Lars Ingebrigtsen @ 2016-05-09 20:35 ` Drew Adams 0 siblings, 0 replies; 35+ messages in thread From: Drew Adams @ 2016-05-09 20:35 UTC (permalink / raw) To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: emacs-devel > >> 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 13:53 Lars Ingebrigtsen ` (2 preceding siblings ...) 2016-05-09 16:31 ` Eli Zaretskii @ 2016-05-09 17:32 ` Óscar Fuentes 2016-05-09 18:08 ` Paul Eggert 3 siblings, 1 reply; 35+ messages in thread From: Óscar Fuentes @ 2016-05-09 17:32 UTC (permalink / raw) To: emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Remove "Recent messages" from `M-x report-emacs-bug' 2016-05-09 17:32 ` Óscar Fuentes @ 2016-05-09 18:08 ` Paul Eggert 0 siblings, 0 replies; 35+ messages in thread From: Paul Eggert @ 2016-05-09 18:08 UTC (permalink / raw) To: Óscar Fuentes, emacs-devel 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. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2016-05-12 0:23 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<87k2j3jq28.fsf@gnus.org> [not found] ` <<6ccbf505-5818-432b-98fa-0733930be2e7@default> [not found] ` <<E1b09ty-0002sA-MS@fencepost.gnu.org> 2016-05-10 16:20 ` Remove "Recent messages" from `M-x report-emacs-bug' Drew Adams 2016-05-11 0:08 ` Richard Stallman [not found] ` <<3ad08202-3529-4613-8f78-ef10b3abb9e2@default> [not found] ` <<E1b0HhP-0006Me-VF@fencepost.gnu.org> 2016-05-11 14:44 ` Drew Adams 2016-05-12 0:23 ` Richard Stallman 2016-05-09 13:53 Lars Ingebrigtsen 2016-05-09 14:20 ` Kaushal Modi 2016-05-09 14:39 ` Kaushal Modi 2016-05-09 14:46 ` Andreas Schwab 2016-05-09 16:34 ` Eli Zaretskii 2016-05-09 14:44 ` Drew Adams 2016-05-10 15:48 ` Richard Stallman 2016-05-09 16:31 ` Eli Zaretskii 2016-05-09 18:25 ` Lars Ingebrigtsen 2016-05-09 19:09 ` Eli Zaretskii 2016-05-09 19:13 ` Lars Ingebrigtsen 2016-05-09 19:17 ` Dmitry Gutov 2016-05-09 19:25 ` Lars Ingebrigtsen 2016-05-09 19:43 ` Eli Zaretskii 2016-05-09 19:55 ` Lars Ingebrigtsen 2016-05-09 20:13 ` Lars Ingebrigtsen 2016-05-10 22:37 ` Glenn Morris 2016-05-09 19:34 ` Kaushal Modi 2016-05-09 19:37 ` Lars Ingebrigtsen 2016-05-09 19:44 ` Kaushal Modi 2016-05-09 19:58 ` Lars Ingebrigtsen 2016-05-09 20:23 ` Kaushal Modi 2016-05-09 20:56 ` Lars Ingebrigtsen 2016-05-09 21:03 ` Kaushal Modi 2016-05-10 10:06 ` Rasmus 2016-05-10 12:32 ` Nicolas Richard 2016-05-09 19:40 ` Eli Zaretskii 2016-05-09 20:07 ` Lars Ingebrigtsen 2016-05-09 20:35 ` Drew Adams 2016-05-09 17:32 ` Óscar Fuentes 2016-05-09 18:08 ` Paul Eggert
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).