bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Drew Adams]

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'
 

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Dani Moncayo]

> 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

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Drew Adams]

> 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.

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Dani Moncayo]

>> 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

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Drew Adams]

> 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.

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Stefan Monnier]

> 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

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Drew Adams]

> > 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.

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Jambunathan K]

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
-- 

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Glenn Morris]

>>   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.

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Drew Adams]

> 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)

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Stefan Monnier]

> 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

bug#13141: 24.3.50; Be able to customize the info included by default for `report-emacs-bug'

[Glenn Morris]

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.

bug#13141: [PATCH]: bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Drew Adams]

[-- 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

bug#13141: please review bug #13141

[Drew Adams]

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

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

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


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

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

bug#13141: please review bug #13141

[Alan Mackenzie]

Hi, Drew.

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

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

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

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


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

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

Let's keep this as simple as possible.

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

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#13141: please review bug #13141

[Drew Adams]

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

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

bug#13141: please review bug #13141

[Drew Adams]

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

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

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

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

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

> we know all about this in Emacs

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

That's logically impossible.

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

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

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

> Let's keep this as simple as possible.

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

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

bug#13141: please review bug #13141

[Xue Fuqiao]

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

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

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

bug#13141: please review bug #13141

[Dmitry Gutov]

"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.

bug#13141: please review bug #13141

[Xue Fuqiao]

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

bug#13141: please review bug #13141

[Drew Adams]

> 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.

bug#13141: please review bug #13141

[Stephen J. Turnbull]

Drew Adams writes:

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

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

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

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

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

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

bug#13141: please review bug #13141

[Stephen J. Turnbull]

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.

bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Drew Adams]

> 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?

bug#13141: please review bug #13141

[Xue Fuqiao]

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

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

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

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

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

bug#13141: please review bug #13141

[Alan Mackenzie]

Good Morning, Drew!

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

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

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

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

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

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

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

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

Er, CC Mode.

> > we know all about this in Emacs

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

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

> That's logically impossible.

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

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

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

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

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

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

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#13141: please review bug #13141

[Xue Fuqiao]

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

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

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

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

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

bug#13141: please review bug #13141

[Eli Zaretskii]

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

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

bug#13141: please review bug #13141

[Drew Adams]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bug#13141: please review bug #13141

[Richard Stallman]

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

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

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

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

bug#13141: please review bug #13141

[Dmitry Gutov]

Richard Stallman <rms@gnu.org> writes:

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

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

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

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

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

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

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

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

bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Stefan Monnier]

> 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

bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Drew Adams]

> > 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?

bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Stefan Monnier]

> 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

bug#13141: 24.3.50; Be able to customize the info included by default for`report-emacs-bug'

[Drew Adams]

> > 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.

bug#13141: please review bug #13141

[Stephen J. Turnbull]

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

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

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

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

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

bug#13141: please review bug #13141

[Drew Adams]

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

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

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

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

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

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

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

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

This is the right approach, IMO:

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

What could be simpler and more flexible?

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

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