* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' @ 2012-12-11 16:00 Drew Adams 2012-12-11 16:12 ` Dani Moncayo ` (3 more replies) 0 siblings, 4 replies; 28+ messages in thread From: Drew Adams @ 2012-12-11 16:00 UTC (permalink / raw) To: 13141 Enhancement request: Let users customize the info that is included by default in the bug-report editing buffer (*unsent mail to bug-gnu-emacs@gnu.org*). Be able to include/exclude any set of the main entries (which start at col 0): * Emacs version info * Important settings * Major mode * Minor modes * Recent input * Recent messages * Load-path shadows * Features The default behavior (without customization) should of course be to include all of these entries/fields. But give users a customization choice, so they need not manually remove the fields they generally prefer not to include. And add commands to the Field menu to insert each of these entries. So if a user customizes to, say, not include field `Recent input' by default, s?he could nevertheless easily include this field by choosing it from the Field menu. And just as for the currently existing Field menu items, add key equivalents. In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600) of 2012-12-07 on MS-W7-DANI Bzr revision: 111150 eggert@cs.ucla.edu-20121207175317-wxhrqxpp0173whq0 Windowing system distributor `Microsoft Corp.', version 5.1.2600 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-1.2.37-lib/include -Ic:/emacs/libs/zlib-1.2.5 -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.0.9-w32-bin/include -Ic:/emacs/libs/libiconv-1.9.2-1-lib/include' ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:00 bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams @ 2012-12-11 16:12 ` Dani Moncayo 2012-12-11 16:18 ` Drew Adams 2012-12-11 19:13 ` Jambunathan K 2012-12-11 16:29 ` Stefan Monnier ` (2 subsequent siblings) 3 siblings, 2 replies; 28+ messages in thread From: Dani Moncayo @ 2012-12-11 16:12 UTC (permalink / raw) To: Drew Adams; +Cc: 13141 > Be able to include/exclude any set of the main entries (which > start at col 0): > > * Emacs version info > * Important settings > * Major mode > * Minor modes > * Recent input > * Recent messages > * Load-path shadows > * Features As a related note, I think it's pointless to send the below text as part of bug reports: This bug report will be sent to the Bug-GNU-Emacs mailing list and the GNU bug tracker at debbugs.gnu.org. Please check that the From: line contains a valid email address. After a delay of up to one day, you should receive an acknowledgment at that address. Please write in English if possible, as the Emacs maintainers usually do not have translators for other languages. Please describe exactly what actions triggered the bug, and the precise symptoms of the bug. If you can, give a recipe starting from `emacs -Q': This information is only useful for the user who is about to write a bug report; it's useless for the rest of people, so IMO it should _not_ be sent. -- Dani Moncayo ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:12 ` Dani Moncayo @ 2012-12-11 16:18 ` Drew Adams 2012-12-11 16:24 ` Dani Moncayo 2012-12-11 19:13 ` Jambunathan K 1 sibling, 1 reply; 28+ messages in thread From: Drew Adams @ 2012-12-11 16:18 UTC (permalink / raw) To: 'Dani Moncayo'; +Cc: 13141 > As a related note, I think it's pointless to send the below text as > part of bug reports: > > This bug report will be sent to... > > This information is only useful for the user who is about to write a > bug report; it's useless for the rest of people, so IMO it should > _not_ be sent. At least on MS Windows, at least using my mail client, that information is not sent. I've always wondered why I sometimes see it in a bug report. In my context, at least, that text is not included in what is pasted when I hit C-v in my mail-client message, after using C-c C-c in Emacs. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:18 ` Drew Adams @ 2012-12-11 16:24 ` Dani Moncayo 2012-12-11 16:28 ` Drew Adams 0 siblings, 1 reply; 28+ messages in thread From: Dani Moncayo @ 2012-12-11 16:24 UTC (permalink / raw) To: Drew Adams; +Cc: 13141 >> As a related note, I think it's pointless to send the below text as >> part of bug reports: >> >> This bug report will be sent to... >> >> This information is only useful for the user who is about to write a >> bug report; it's useless for the rest of people, so IMO it should >> _not_ be sent. > > At least on MS Windows, at least using my mail client, that information is not > sent. I've always wondered why I sometimes see it in a bug report. > > In my context, at least, that text is not included in what is pasted when I hit > C-v in my mail-client message, after using C-c C-c in Emacs. Ah, well, so far I've always copied & pasted manually the text from the Emacs buffer to my email program (the browser). If Emacs already discard that text, then ok, that's TRT. :) -- Dani Moncayo ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:24 ` Dani Moncayo @ 2012-12-11 16:28 ` Drew Adams 0 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2012-12-11 16:28 UTC (permalink / raw) To: 'Dani Moncayo'; +Cc: 13141 > Ah, well, so far I've always copied & pasted manually the text from > the Emacs buffer to my email program (the browser). If Emacs already > discard that text, then ok, that's TRT. :) I use C-c C-c in the editing buffer. That automatically opens a new Outlook message that is addressed for bug reporting. It has a single line of text in the message body that tells me that I can paste (e.g. using C-v) my bug-report text into the message body. I select that line of text and hit C-v to replace it with my report. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:12 ` Dani Moncayo 2012-12-11 16:18 ` Drew Adams @ 2012-12-11 19:13 ` Jambunathan K 2012-12-11 19:19 ` Glenn Morris 2012-12-11 19:27 ` bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 1 sibling, 2 replies; 28+ messages in thread From: Jambunathan K @ 2012-12-11 19:13 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13141 Dani Moncayo <dmoncayo@gmail.com> writes: > As a related note, I think it's pointless to send the below text as > part of bug reports: > > This bug report will be sent to the Bug-GNU-Emacs mailing list > [...] > starting from `emacs -Q': > > This information is only useful for the user who is about to write a > bug report; it's useless for the rest of people, so IMO it should > _not_ be sent. M-x customize-variable RET report-emacs-bug-no-explanations RET -- ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 19:13 ` Jambunathan K @ 2012-12-11 19:19 ` Glenn Morris 2012-12-11 19:34 ` Stefan Monnier 2012-12-11 19:27 ` bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 1 sibling, 1 reply; 28+ messages in thread From: Glenn Morris @ 2012-12-11 19:19 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13141 >> This bug report will be sent to the Bug-GNU-Emacs mailing list >> [...] >> starting from `emacs -Q': >> >> This information is only useful for the user who is about to write a >> bug report; it's useless for the rest of people, so IMO it should >> _not_ be sent. It isn't sent. There is a hook that strips it out, but it is easy to defeat it, which is why you sometimes see it. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 19:19 ` Glenn Morris @ 2012-12-11 19:34 ` Stefan Monnier 2013-01-20 9:45 ` bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' Drew Adams 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2012-12-11 19:34 UTC (permalink / raw) To: Glenn Morris; +Cc: 13141 > It isn't sent. There is a hook that strips it out, but it is easy to > defeat it, which is why you sometimes see it. I've just changed this text to be a display text-property, so you can see it, but it's not really part of the buffer: copy&paste into another application will not copy it and it doesn't need to be stripped explicitly before sending. IOW it now requires extra work to keep the text, instead of requiring extra work to remove it. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2012-12-11 19:34 ` Stefan Monnier @ 2013-01-20 9:45 ` Drew Adams 2013-01-21 1:22 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Drew Adams @ 2013-01-20 9:45 UTC (permalink / raw) To: 'Stefan Monnier', 'Glenn Morris'; +Cc: 13141 > I've just changed this text to be a display text-property, so you can > see it, but it's not really part of the buffer: copy&paste > into another application will not copy it and it doesn't need to be > stripped explicitly before sending. > IOW it now requires extra work to keep the text, instead of requiring > extra work to remove it. That change unfortunately breaks fitting the frame to the buffer (using my fit-frame.el), horribly. Can't you please find a different solution to whatever your change was trying to solve, a solution that has the text actually in the buffer so that it is measurable for things like fitting, as before? I don't think there was a real problem that you needed to solve. How many users actually copied the text, and how big a problem was their doing so? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2013-01-20 9:45 ` bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' Drew Adams @ 2013-01-21 1:22 ` Stefan Monnier 2013-01-21 1:35 ` Drew Adams 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2013-01-21 1:22 UTC (permalink / raw) To: Drew Adams; +Cc: 13141 > That change unfortunately breaks fitting the frame to the buffer (using my > fit-frame.el), horribly. I'd rather fix fit-frame.el so it handles this case as well. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2013-01-21 1:22 ` Stefan Monnier @ 2013-01-21 1:35 ` Drew Adams 2013-01-21 1:54 ` Stefan Monnier 0 siblings, 1 reply; 28+ messages in thread From: Drew Adams @ 2013-01-21 1:35 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 13141 > > That change unfortunately breaks fitting the frame to the > > buffer (using my fit-frame.el), horribly. > > I'd rather fix fit-frame.el so it handles this case as well. Suggestions welcome. ;-) I've thought a little about it. I could check each character for a display property that is, in effect, a replacement string (as in this case), and then get its width. But that would slow things down considerably. Currently I just get the line width for each line using `end-of-line'. I believe there is a longstanding Emacs bug regarding the same kind of thing for a vanilla Emacs function that does some window/buffer fitting. Perhaps you recall the discussion from a few years back. The plan/hope was to make it DTRT in terms of what actually gets displayed, not just what is inserted (text, images) in the buffer. AFAIK, nothing ever came of those hopes. fit-frame.el suffers from the same lack of magic. Anyway, clearly, for this latest bug (breaking fit-frame), it is FAR easier to revert to what we had before your fix or to find some other solution to the problem, as you saw it, of users copying text they "shouldn't". It is far easier to fix that than it would be to fix fit-frame.el's calculation of needed frame size so that it takes all display artifacts into account. We should not let the ideal become the enemy of the good. But as I said, if you have some simple suggestions for fit-frame.el in this regard, they are welcome. Even then, while waiting, it would be good to fix this minor unwarranted-text-copying problem some other way than your `display' property hack. I don't even see it as a real problem that needed fixing, personally, or at least not an important one. How much has it really been a problem in practice that users included instructions in their bug-report text? ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2013-01-21 1:35 ` Drew Adams @ 2013-01-21 1:54 ` Stefan Monnier 2013-01-21 2:09 ` Drew Adams 0 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2013-01-21 1:54 UTC (permalink / raw) To: Drew Adams; +Cc: 13141 > I've thought a little about it. I could check each character for a display > property that is, in effect, a replacement string (as in this case), and then > get its width. It should use things along the lines of vertical-motion. If those primitives don't cut it, just send a request for feature. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2013-01-21 1:54 ` Stefan Monnier @ 2013-01-21 2:09 ` Drew Adams 0 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2013-01-21 2:09 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 13141 > > I've thought a little about it. I could check each > > character for a display property that is, in effect, a > > replacement string (as in this case), and then get its width. > > It should use things along the lines of vertical-motion. If those > primitives don't cut it, just send a request for feature. OK, I'll keep that in mind. But the fact that Emacs itself has still not been able to do this (calculate the effective display dimensions for a buffer), does not encourage me to strike out in that wilderness. If I had more time I would perhaps experiment. But fit-frame is something that works well, and I don't want to fiddle with it too much without a clear idea about a simple solution/improvement. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 19:13 ` Jambunathan K 2012-12-11 19:19 ` Glenn Morris @ 2012-12-11 19:27 ` Drew Adams 1 sibling, 0 replies; 28+ messages in thread From: Drew Adams @ 2012-12-11 19:27 UTC (permalink / raw) To: 'Jambunathan K', 'Dani Moncayo'; +Cc: 13141 > M-x customize-variable RET report-emacs-bug-no-explanations RET In my request, it would not be simply a boolean, as suggested by the name you used. Users would be able to pick and choose which fields they want to include. Something like this: (defcustom report-emacs-bug-included-fields '(version settings major-mode minor-modes recent-input recent-messages load-shadows features) "Fields to include by default for command `report-emacs-bug'. The fields are included automatically in the buffer where you edit your bug report." :type '(set (const :tag "Emacs version info" version) (const :tag "Important settings" settings) (const :tag "Major mode" major-mode) (const :tag "Minor modes" minor-modes) (const :tag "Recent input" recent-input) (const :tag "Recent messages" recent-messages) (const :tag "Load-path shadows" load-shadows) (const :tag "Features" features)) :group 'convenience) ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:00 bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 2012-12-11 16:12 ` Dani Moncayo @ 2012-12-11 16:29 ` Stefan Monnier 2012-12-11 16:37 ` Drew Adams 2012-12-11 19:45 ` Glenn Morris 2013-01-19 23:10 ` bug#13141: please review bug #13141 Drew Adams 3 siblings, 1 reply; 28+ messages in thread From: Stefan Monnier @ 2012-12-11 16:29 UTC (permalink / raw) To: Drew Adams; +Cc: 13141 > Enhancement request: Let users customize the info that is included > by default in the bug-report editing buffer > (*unsent mail to bug-gnu-emacs@gnu.org*). FWIW, I find most of those info useless to me. Stefan ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:29 ` Stefan Monnier @ 2012-12-11 16:37 ` Drew Adams 0 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2012-12-11 16:37 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 13141 > > Enhancement request: Let users customize the info that is included > > by default in the bug-report editing buffer > > (*unsent mail to bug-gnu-emacs@gnu.org*). > > FWIW, I find most of those info useless to me. I cannot speak to how useful some of that info might be to Emacs Dev. (But I agree that the text mostly represents noise.) My request here is for users to be able to express their preference in a general way, instead of having to remove such text each time, if they don't want it included. The problem, I guess, is that if this info is not captured from the session when reporting then it is difficult for Emacs Dev to obtain it later. You can't really ask a user to show you the last 200 messages from a session that might no longer exist. So I suppose there can be some value to some of that info some of the time, but it's not clear what the right approach is wrt what to include by default. Anyway, I have no objection to including it all by default. But we should let users set up their own default behavior wrt what gets included. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' 2012-12-11 16:00 bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 2012-12-11 16:12 ` Dani Moncayo 2012-12-11 16:29 ` Stefan Monnier @ 2012-12-11 19:45 ` Glenn Morris 2012-12-11 19:59 ` bug#13141: [PATCH]: bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' Drew Adams 2013-01-19 23:10 ` bug#13141: please review bug #13141 Drew Adams 3 siblings, 1 reply; 28+ messages in thread From: Glenn Morris @ 2012-12-11 19:45 UTC (permalink / raw) To: 13141 tags 13141 wontfix stop "Drew Adams" wrote: > Enhancement request: Let users customize the info that is included > by default in the bug-report editing buffer There is no need for such complexity. You don't have to faithfully use emacs -Q; M-x report-emacs-bug for each of your 1000+ bug reports, you can just mail bug-gnu-emacs and make your own call as to what info is needed. For example, it is obvious that none of the boilerplate information has any relevance to this request. And configuration options have no relevance to doc bugs, etc. If you don't want to make that call, then accept the defaults and move on. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: [PATCH]: bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' 2012-12-11 19:45 ` Glenn Morris @ 2012-12-11 19:59 ` Drew Adams 0 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2012-12-11 19:59 UTC (permalink / raw) To: 'Glenn Morris', 13141 [-- Attachment #1: Type: text/plain, Size: 738 bytes --] > tags 13141 wontfix > stop > > "Drew Adams" wrote: > > > Enhancement request: Let users customize the info that is included > > by default in the bug-report editing buffer > > There is no need for such complexity. > You don't have to faithfully use emacs -Q; M-x > report-emacs-bug for each > of your 1000+ bug reports, you can just mail bug-gnu-emacs > and make your > own call as to what info is needed. For example, it is > obvious that none > of the boilerplate information has any relevance to this request. > And configuration options have no relevance to doc bugs, etc. > If you don't want to make that call, then accept the defaults and move > on. This is not about me. (Is it about you, perhaps?) Attached is a patch. [-- Attachment #2: emacsbug.patch --] [-- Type: application/octet-stream, Size: 10566 bytes --] diff -c emacsbug.el emacsbug-patched-2012-12-11.el *** emacsbug.el Tue Dec 11 11:41:54 2012 --- emacsbug-patched-2012-12-11.el Tue Dec 11 11:53:46 2012 *************** *** 58,63 **** --- 58,81 ---- :group 'emacsbug :type 'boolean) + (defcustom report-emacs-bug-included-fields '(version settings major-mode + minor-modes recent-input + recent-messages load-shadows + features) + "Fields to include by default for command `report-emacs-bug'. + The fields are included automatically in the buffer where you edit + your bug report." + :type '(set + (const :tag "Emacs version info" version) + (const :tag "Important settings" settings) + (const :tag "Major mode" major-mode) + (const :tag "Minor modes" minor-modes) + (const :tag "Recent input" recent-input) + (const :tag "Recent messages" recent-messages) + (const :tag "Load-path shadows" load-shadows) + (const :tag "Features" features)) + :group 'convenience) + ;; User options end here. (defvar report-emacs-bug-orig-text nil *************** *** 229,323 **** (let ((txt (delete-and-extract-region (1+ user-point) (point)))) (insert (propertize "\n" 'display txt))) ! (insert "\n\nIn " (emacs-version) "\n") ! (if (stringp emacs-bzr-version) ! (insert "Bzr revision: " emacs-bzr-version "\n")) ! (if (fboundp 'x-server-vendor) ! (condition-case nil ! ;; This is used not only for X11 but also W32 and others. ! (insert "Windowing system distributor `" (x-server-vendor) ! "', version " ! (mapconcat 'number-to-string (x-server-version) ".") "\n") ! (error t))) ! (let ((lsb (with-temp-buffer ! (if (eq 0 (ignore-errors ! (call-process "lsb_release" nil '(t nil) ! nil "-d"))) ! (buffer-string))))) ! (if (stringp lsb) ! (insert "System " lsb "\n"))) ! (when (and system-configuration-options ! (not (equal system-configuration-options ""))) ! (insert "Configured using:\n `configure " ! system-configuration-options "'\n\n") ! (fill-region (line-beginning-position -1) (point))) ! (insert "Important settings:\n") ! (mapc ! (lambda (var) ! (let ((val (getenv var))) ! (if val (insert (format " value of $%s: %s\n" var val))))) ! '("EMACSDATA" "EMACSDOC" "EMACSLOADPATH" "EMACSPATH" ! "LC_ALL" "LC_COLLATE" "LC_CTYPE" "LC_MESSAGES" ! "LC_MONETARY" "LC_NUMERIC" "LC_TIME" "LANG" "XMODIFIERS")) ! (insert (format " locale-coding-system: %s\n" locale-coding-system)) ! (insert (format " default enable-multibyte-characters: %s\n" ! (default-value 'enable-multibyte-characters))) ! (insert "\n") ! (insert (format "Major mode: %s\n" ! (format-mode-line ! (buffer-local-value 'mode-name from-buffer) ! nil nil from-buffer))) ! (insert "\n") ! (insert "Minor modes in effect:\n") ! (dolist (mode minor-mode-list) ! (and (boundp mode) (buffer-local-value mode from-buffer) ! (insert (format " %s: %s\n" mode ! (buffer-local-value mode from-buffer))))) ! (insert "\n") ! (insert "Recent input:\n") ! (let ((before-keys (point))) ! (insert (mapconcat (lambda (key) ! (if (or (integerp key) ! (symbolp key) ! (listp key)) ! (single-key-description key) ! (prin1-to-string key nil))) ! (or recent-keys (recent-keys)) ! " ")) ! (save-restriction ! (narrow-to-region before-keys (point)) ! (goto-char before-keys) ! (while (progn (move-to-column 50) (not (eobp))) ! (search-forward " " nil t) ! (insert "\n")))) ! (let ((message-buf (get-buffer "*Messages*"))) ! (if message-buf ! (let (beg-pos ! (end-pos message-end-point)) ! (with-current-buffer message-buf ! (goto-char end-pos) ! (forward-line -10) ! (setq beg-pos (point))) ! (insert "\n\nRecent messages:\n") ! (insert-buffer-substring message-buf beg-pos end-pos)))) ! ;; After Recent messages, to avoid the messages produced by ! ;; list-load-path-shadows. ! (unless (looking-back "\n") (insert "\n")) ! (insert "\n") ! (insert "Load-path shadows:\n") ! (let* ((msg "Checking for load-path shadows...") ! (result "done") ! (shadows (progn (message "%s" msg) ! (condition-case nil (list-load-path-shadows t) ! (error ! (setq result "error") ! "Error during checking"))))) ! (message "%s%s" msg result) ! (insert (if (zerop (length shadows)) ! "None found.\n" ! shadows))) ! (insert (format "\nFeatures:\n%s\n" features)) (fill-region (line-beginning-position 0) (point)) ;; This is so the user has to type something in order to send easily. (use-local-map (nconc (make-sparse-keymap) (current-local-map))) --- 247,349 ---- (let ((txt (delete-and-extract-region (1+ user-point) (point)))) (insert (propertize "\n" 'display txt))) ! (when (member 'version report-emacs-bug-included-fields) ! (insert "\n\nIn " (emacs-version) "\n") ! (if (stringp emacs-bzr-version) ! (insert "Bzr revision: " emacs-bzr-version "\n")) ! (if (fboundp 'x-server-vendor) ! (condition-case nil ! ;; This is used not only for X11 but also W32 and others. ! (insert "Windowing system distributor `" (x-server-vendor) ! "', version " ! (mapconcat 'number-to-string (x-server-version) ".") "\n") ! (error t))) ! (let ((lsb (with-temp-buffer ! (if (eq 0 (ignore-errors ! (call-process "lsb_release" nil '(t nil) ! nil "-d"))) ! (buffer-string))))) ! (if (stringp lsb) ! (insert "System " lsb "\n"))) ! (when (and system-configuration-options ! (not (equal system-configuration-options ""))) ! (insert "Configured using:\n `configure " ! system-configuration-options "'\n\n") ! (fill-region (line-beginning-position -1) (point)))) ! (when (member 'settings report-emacs-bug-included-fields) ! (insert "Important settings:\n") ! (mapc ! (lambda (var) ! (let ((val (getenv var))) ! (if val (insert (format " value of $%s: %s\n" var val))))) ! '("EMACSDATA" "EMACSDOC" "EMACSLOADPATH" "EMACSPATH" ! "LC_ALL" "LC_COLLATE" "LC_CTYPE" "LC_MESSAGES" ! "LC_MONETARY" "LC_NUMERIC" "LC_TIME" "LANG" "XMODIFIERS")) ! (insert (format " locale-coding-system: %s\n" locale-coding-system)) ! (insert (format " default enable-multibyte-characters: %s\n" ! (default-value 'enable-multibyte-characters))) ! (insert "\n")) ! (when (member 'major-mode report-emacs-bug-included-fields) ! (insert (format "Major mode: %s\n" ! (format-mode-line ! (buffer-local-value 'mode-name from-buffer) ! nil nil from-buffer))) ! (insert "\n")) ! (when (member 'minor-modes report-emacs-bug-included-fields) ! (insert "Minor modes in effect:\n") ! (dolist (mode minor-mode-list) ! (and (boundp mode) (buffer-local-value mode from-buffer) ! (insert (format " %s: %s\n" mode ! (buffer-local-value mode from-buffer))))) ! (insert "\n")) ! (when (member 'recent-input report-emacs-bug-included-fields) ! (insert "Recent input:\n") ! (let ((before-keys (point))) ! (insert (mapconcat (lambda (key) ! (if (or (integerp key) ! (symbolp key) ! (listp key)) ! (single-key-description key) ! (prin1-to-string key nil))) ! (or recent-keys (recent-keys)) ! " ")) ! (save-restriction ! (narrow-to-region before-keys (point)) ! (goto-char before-keys) ! (while (progn (move-to-column 50) (not (eobp))) ! (search-forward " " nil t) ! (insert "\n"))))) ! (when (member 'recent-messages report-emacs-bug-included-fields) ! (let ((message-buf (get-buffer "*Messages*"))) ! (if message-buf ! (let (beg-pos ! (end-pos message-end-point)) ! (with-current-buffer message-buf ! (goto-char end-pos) ! (forward-line -10) ! (setq beg-pos (point))) ! (insert "\n\nRecent messages:\n") ! (insert-buffer-substring message-buf beg-pos end-pos)))) ! ;; After Recent messages, to avoid the messages produced by ! ;; list-load-path-shadows. ! (unless (looking-back "\n") ! (insert "\n")) (insert "\n")) ! (when (member 'load-shadows report-emacs-bug-included-fields) ! (insert "Load-path shadows:\n") ! (let* ((msg "Checking for load-path shadows...") ! (result "done") ! (shadows (progn (message "%s" msg) ! (condition-case nil (list-load-path-shadows t) ! (error ! (setq result "error") ! "Error during checking"))))) ! (message "%s%s" msg result) ! (insert (if (zerop (length shadows)) ! "None found.\n" ! shadows)))) ! (when (member 'features report-emacs-bug-included-fields) ! (insert (format "\nFeatures:\n%s\n" features))) (fill-region (line-beginning-position 0) (point)) ;; This is so the user has to type something in order to send easily. (use-local-map (nconc (make-sparse-keymap) (current-local-map))) Diff finished. Tue Dec 11 11:54:47 2012 ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: please review bug #13141 2012-12-11 16:00 bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams ` (2 preceding siblings ...) 2012-12-11 19:45 ` Glenn Morris @ 2013-01-19 23:10 ` Drew Adams 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:35 ` Dmitry Gutov 3 siblings, 2 replies; 28+ messages in thread From: Drew Adams @ 2013-01-19 23:10 UTC (permalink / raw) To: emacs-devel; +Cc: 13141 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-19 23:10 ` bug#13141: please review bug #13141 Drew Adams @ 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao ` (3 more replies) 2013-01-20 0:35 ` Dmitry Gutov 1 sibling, 4 replies; 28+ messages in thread From: Dmitry Gutov @ 2013-01-20 0:35 UTC (permalink / raw) To: Drew Adams; +Cc: 13141, emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > 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? Personally, I disagree that the user should choose what information to include. The report goes to Emacs maintainers, so they should pick the always-useful parts (say, the version, bzr revision and build options) and leave out the noise. While possibly still providing interactive commands allowing to insert the additional information in a follow-up email. I also think this is one of the parts of Emacs where backwards compatibility is the least important, so it's odd that the bug reporting interface hasn't changed much in years. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: please review bug #13141 2013-01-20 0:35 ` Dmitry Gutov @ 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 0:54 ` Xue Fuqiao ` (2 subsequent siblings) 3 siblings, 0 replies; 28+ messages in thread From: Xue Fuqiao @ 2013-01-20 0:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13141, emacs-devel On Sun, 20 Jan 2013 04:35:24 +0400 Dmitry Gutov <dgutov@yandex.ru> wrote: > Personally, I disagree that the user should choose what information to > include. The report goes to Emacs maintainers, so they should pick the > always-useful parts (say, the version, bzr revision and build options) and > leave out the noise. In (info "(emacs) Checklist"): You may feel that some of the information inserted by `M-x report-emacs-bug' is not relevant, but unless you are absolutely sure it is best to leave it, so that the developers can decide for themselves. But *extensible and customizable* (and self-documenting) are the core of Emacs. Experienced users *know* that what information should be go to the Emacs developers. It also lightens the burden of Emacs developers. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao @ 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 1:03 ` Drew Adams 2013-01-20 1:03 ` Drew Adams 3 siblings, 2 replies; 28+ messages in thread From: Xue Fuqiao @ 2013-01-20 0:54 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 13141, Drew Adams, emacs-devel On Sun, 20 Jan 2013 04:35:24 +0400 Dmitry Gutov <dgutov@yandex.ru> wrote: > Personally, I disagree that the user should choose what information to > include. The report goes to Emacs maintainers, so they should pick the > always-useful parts (say, the version, bzr revision and build options) and > leave out the noise. In (info "(emacs) Checklist"): You may feel that some of the information inserted by `M-x report-emacs-bug' is not relevant, but unless you are absolutely sure it is best to leave it, so that the developers can decide for themselves. But *extensible and customizable* (and self-documenting) are the core of Emacs. Experienced users *know* that what information should be go to the Emacs developers. It also lightens the burden of Emacs developers. -- Best regards, Xue Fuqiao. http://www.emacswiki.org/emacs/XueFuqiao ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 0:54 ` Xue Fuqiao @ 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 19:46 ` Harald Hanche-Olsen 2013-01-20 7:19 ` Stephen J. Turnbull 1 sibling, 1 reply; 28+ messages in thread From: Stephen J. Turnbull @ 2013-01-20 7:19 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13141, emacs-devel, Drew Adams, Dmitry Gutov Xue Fuqiao writes: > But *extensible and customizable* (and self-documenting) are the core > of Emacs. Experienced users *know* that what information should be go > to the Emacs developers. Experienced developers know that what experienced users "know" often enough just ain't so. The only case where users are in a good position to decide is about privacy-sensitive information that might be in traces or keystroke logs, etc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: bug#13141: please review bug #13141 2013-01-20 7:19 ` Stephen J. Turnbull @ 2013-01-20 19:46 ` Harald Hanche-Olsen 0 siblings, 0 replies; 28+ messages in thread From: Harald Hanche-Olsen @ 2013-01-20 19:46 UTC (permalink / raw) To: emacs-devel ["Stephen J. Turnbull" <stephen@xemacs.org> (2013-01-20 07:19:10 UTC)] > Experienced developers know that what experienced users "know" often > enough just ain't so. > > The only case where users are in a good position to decide is about > privacy-sensitive information that might be in traces or keystroke > logs, etc. I admit to being one of those who routinely deletes much of the noise before submitting a bug report. But then, whenever possible, I try to figure out a way to reproduce the bug starting from emacs -Q. In which case Major and minor modes, recent input, and recent messages are truly irrelevant, and so I delete them before submitting the bug report. (An extreme case is #11358, where I have deleted *all* the predetermined info.) In any case, I hardly ever report a bug immediately after encountering it. I am usually too busy trying to get stuff done, so I finish that first, then investigate the bug, typically in a separate emacs instance, and then submit a bug report. In which case I am quite confident that recent input and messages are beside the point, so I delete them. But perhaps I am very unusual as bug reporters go. In any case, I don't really see the need for more options. If I can delete irrelevant parts from the bug reports, so can anybody else. I don't think we need to make it any easier than it already is, especially as it appears some people are already deleting more than they should. But perhaps they should be told, somehow, to review recent input and messages for private content that they may not wish to reveal to the world. - Harald ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: please review bug #13141 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 7:19 ` Stephen J. Turnbull @ 2013-01-20 7:19 ` Stephen J. Turnbull 1 sibling, 0 replies; 28+ messages in thread From: Stephen J. Turnbull @ 2013-01-20 7:19 UTC (permalink / raw) To: Xue Fuqiao; +Cc: 13141, Dmitry Gutov, emacs-devel Xue Fuqiao writes: > But *extensible and customizable* (and self-documenting) are the core > of Emacs. Experienced users *know* that what information should be go > to the Emacs developers. Experienced developers know that what experienced users "know" often enough just ain't so. The only case where users are in a good position to decide is about privacy-sensitive information that might be in traces or keystroke logs, etc. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: please review bug #13141 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 0:54 ` Xue Fuqiao @ 2013-01-20 1:03 ` Drew Adams 2013-01-20 1:03 ` Drew Adams 3 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2013-01-20 1:03 UTC (permalink / raw) To: 'Dmitry Gutov'; +Cc: 13141, emacs-devel > Personally, I disagree that the user should choose what information > to include. Too bad for you, then. The user already chooses that. As well s?he should. A user should _of course_ be able to choose what information s?he sends. This is about the information that is _automatically_ inserted into the report-preparation buffer. If the user does not want to send some of that info then s?he need not, even today, as Xue Fuqiao made clear. All my patch does is make it easier for a user to not send this or that info. > The report goes to Emacs maintainers, so they should pick the > always-useful parts The maintainers should pick the parts that they think should be provided _by default_, just as they do today. They cannot and should not pick, in place of the user, what the user actually sends. And one of the maintainers has already stated, FWIW, that he finds "most of those info useless". > (say, the version, bzr revision and build options) and leave > out the noise. One person's noise is another's important information. That's part of the point of providing this option: if a user so chooses, s?he can easily cut down on what s?he considers noise. Let users decide. Emacs proposes, users dispose. And I repeat, the default behavior - the information that is automatically included by default - does NOT change with this patch. > While possibly still providing interactive commands > allowing to insert the additional information in a follow-up email. Nothing wrong with that, IMO. Consider submitting an enhancement request for the addition of such commands. > I also think this is one of the parts of Emacs where backwards > compatibility is the least important, so it's odd that the > bug reporting interface hasn't changed much in years. You are welcome to submit an enhancement request to change the set of info that gets inserted by default. My patch is not so radical as what you are requesting. It maintains the status quo wrt that set of info - the default behavior. It simply makes it easy for a user to customize what which info gets inserted by default. There already is a user option, `report-emacs-bug-no-explanations', that turns it all off. My patch just gives users more control than an on/off switch. ^ permalink raw reply [flat|nested] 28+ messages in thread
* RE: bug#13141: please review bug #13141 2013-01-20 0:35 ` Dmitry Gutov ` (2 preceding siblings ...) 2013-01-20 1:03 ` Drew Adams @ 2013-01-20 1:03 ` Drew Adams 3 siblings, 0 replies; 28+ messages in thread From: Drew Adams @ 2013-01-20 1:03 UTC (permalink / raw) To: 'Dmitry Gutov'; +Cc: 13141, emacs-devel > Personally, I disagree that the user should choose what information > to include. Too bad for you, then. The user already chooses that. As well s?he should. A user should _of course_ be able to choose what information s?he sends. This is about the information that is _automatically_ inserted into the report-preparation buffer. If the user does not want to send some of that info then s?he need not, even today, as Xue Fuqiao made clear. All my patch does is make it easier for a user to not send this or that info. > The report goes to Emacs maintainers, so they should pick the > always-useful parts The maintainers should pick the parts that they think should be provided _by default_, just as they do today. They cannot and should not pick, in place of the user, what the user actually sends. And one of the maintainers has already stated, FWIW, that he finds "most of those info useless". > (say, the version, bzr revision and build options) and leave > out the noise. One person's noise is another's important information. That's part of the point of providing this option: if a user so chooses, s?he can easily cut down on what s?he considers noise. Let users decide. Emacs proposes, users dispose. And I repeat, the default behavior - the information that is automatically included by default - does NOT change with this patch. > While possibly still providing interactive commands > allowing to insert the additional information in a follow-up email. Nothing wrong with that, IMO. Consider submitting an enhancement request for the addition of such commands. > I also think this is one of the parts of Emacs where backwards > compatibility is the least important, so it's odd that the > bug reporting interface hasn't changed much in years. You are welcome to submit an enhancement request to change the set of info that gets inserted by default. My patch is not so radical as what you are requesting. It maintains the status quo wrt that set of info - the default behavior. It simply makes it easy for a user to customize what which info gets inserted by default. There already is a user option, `report-emacs-bug-no-explanations', that turns it all off. My patch just gives users more control than an on/off switch. ^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#13141: please review bug #13141 2013-01-19 23:10 ` bug#13141: please review bug #13141 Drew Adams 2013-01-20 0:35 ` Dmitry Gutov @ 2013-01-20 0:35 ` Dmitry Gutov 1 sibling, 0 replies; 28+ messages in thread From: Dmitry Gutov @ 2013-01-20 0:35 UTC (permalink / raw) To: Drew Adams; +Cc: 13141, emacs-devel "Drew Adams" <drew.adams@oracle.com> writes: > 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? Personally, I disagree that the user should choose what information to include. The report goes to Emacs maintainers, so they should pick the always-useful parts (say, the version, bzr revision and build options) and leave out the noise. While possibly still providing interactive commands allowing to insert the additional information in a follow-up email. I also think this is one of the parts of Emacs where backwards compatibility is the least important, so it's odd that the bug reporting interface hasn't changed much in years. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2013-01-21 2:09 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-12-11 16:00 bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 2012-12-11 16:12 ` Dani Moncayo 2012-12-11 16:18 ` Drew Adams 2012-12-11 16:24 ` Dani Moncayo 2012-12-11 16:28 ` Drew Adams 2012-12-11 19:13 ` Jambunathan K 2012-12-11 19:19 ` Glenn Morris 2012-12-11 19:34 ` Stefan Monnier 2013-01-20 9:45 ` bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' Drew Adams 2013-01-21 1:22 ` Stefan Monnier 2013-01-21 1:35 ` Drew Adams 2013-01-21 1:54 ` Stefan Monnier 2013-01-21 2:09 ` Drew Adams 2012-12-11 19:27 ` bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug' Drew Adams 2012-12-11 16:29 ` Stefan Monnier 2012-12-11 16:37 ` Drew Adams 2012-12-11 19:45 ` Glenn Morris 2012-12-11 19:59 ` bug#13141: [PATCH]: bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug' Drew Adams 2013-01-19 23:10 ` bug#13141: please review bug #13141 Drew Adams 2013-01-20 0:35 ` Dmitry Gutov 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 0:54 ` Xue Fuqiao 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 19:46 ` Harald Hanche-Olsen 2013-01-20 7:19 ` Stephen J. Turnbull 2013-01-20 1:03 ` Drew Adams 2013-01-20 1:03 ` Drew Adams 2013-01-20 0:35 ` Dmitry Gutov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.