From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: please review bug #13141 Date: Mon, 21 Jan 2013 14:20:31 -0800 Message-ID: <33138BB23B3E4FF383A1AA44C6D2EF08@us.oracle.com> References: <50FCEBE3.6070806@acdlabs.ru> <20130121.162653.2105027028246728109.hanche@math.ntnu.no> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1358806854 24459 80.91.229.3 (21 Jan 2013 22:20:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Jan 2013 22:20:54 +0000 (UTC) To: "'Harald Hanche-Olsen'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 21 23:21:13 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TxPjp-0007xh-Uo for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2013 23:21:10 +0100 Original-Received: from localhost ([::1]:49066 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxPjY-00064G-Sw for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2013 17:20:52 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:56662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxPjV-00063v-BP for emacs-devel@gnu.org; Mon, 21 Jan 2013 17:20:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TxPjT-0004ny-O7 for emacs-devel@gnu.org; Mon, 21 Jan 2013 17:20:49 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:32684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TxPjT-0004np-4z for emacs-devel@gnu.org; Mon, 21 Jan 2013 17:20:47 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0LMKjSA025893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jan 2013 22:20:45 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r0LMKhX8010042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jan 2013 22:20:45 GMT Original-Received: from abhmt120.oracle.com (abhmt120.oracle.com [141.146.116.72]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r0LMKh5p011329; Mon, 21 Jan 2013 16:20:43 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Jan 2013 14:20:43 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130121.162653.2105027028246728109.hanche@math.ntnu.no> Thread-Index: Ac3368ZO7eT7uqHZSRCPseysx/mgGgAMDDBQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:156561 Archived-At: > > That doesn't mean that the emacs session where you submit the report > > must be an emacs -Q session. And some bug reports do not require a > > recipe from emacs -Q, though that's always a good idea. > > I don't know about others, but I can't possibly send email from an > emacs -Q session without going through a lot of trouble. Yes. It can be easier to just copy the composed report text from Emacs to an external mail client. Simple. Trivial. (And not clearly stated to users, AFAICT.) Configuring Emacs to send mail is understandably non-trivial. The good news is that one _need not_ use Emacs to send mail, including a bug report, provided one has an external mail client. (Users deserve to hear that good news.) > Which means recent input and messages are almost always irrelevant. No, not necessarily. You can copy them to a different Emacs session where you report the bug, if you like. They are irrelevant only if in fact they are irrelevant to the particular bug report at hand. You, the reporter, are the immediate judge of that. If you think that that info is in fact irrelevant, then don't bother to include it in your report. If you think it is relevant, you can always copy it to another Emacs session where mail is configured, or copy it to an external mail client, if you have one. > It might make sense to only include this data provided > (y-or-n-p "Did you encounter the bug just now in this emacs session?") Emacs (and Emacs Dev) should not try to be so clever. It should not get fixated on its automatic capturing of session information. Just let users use their own judgment and act accordingly. But let's give them the means to do so easily. Emacs should not try to second-guess users. In general, it should avoid interrogating them unnecessarily. Let them act as they like, with reasonable tools that help them get the job done. At bottom, the user is just sending an email to bug-gnu-emacs@gnu.org - nothing more. Sheesh, not a big deal. All `report-emacs-bug' is for is to help you do that. It is only a convenience command. That Emacs pops up a buffer for you to compose the report text is the main convenience. That Emacs can address and later send the completed mail message, using a mail client that is either integrated with Emacs or external to it, is another convenience. That Emacs can fill the report composition buffer with some automatically captured info about the current session is yet another convenience. These are all (relatively minor) conveniences - nothing more. The real, and trivial, message can be lost in all of this: Report bugs to bug-gnu-emacs@gnu.org. Our current user interrogation, before mail has been configured, is unfortunate. IF configuration is to be done, then Emacs needs the answers, of course. In that case ONLY do we need to call in the Grand Inquisitor, so why start users out with him? Configuration is _not needed_ to send a bug report, if you have an external mail client, which is true of most people nowadays. That should be the default, the starting point in our instructions to users. Start with the simple method, and make clear that the complex method is optional. The first (and hence potentially the only) question the dialog should ask is simply whether you want to use Emacs itself to send the mail. But even for that there is no necessary reason to ask the user. The `report-emacs-bug' instructions should simply say: After composing your report here, copy it to a new mail message in your mail client, and send it to bug-gnu-emacs@gnu.org. Instead, they dive immediately into saying that Emacs WILL send a mail, etc. The instructions could continue by saying that IF you prefer instead that Emacs send the mail for you, then hit `C-c C-c', which will lead you through the necessary steps to send it. IOW, there is no absolute need for Emacs to ever ask anything, in order for a user to send a bug report. Emacs should keep it simple, to start with. The complexity is optional, and it should be presented as such, AFTER telling users they can just send an email to bug-gnu-emacs@gnu.org. The bug reporting process has gotten out of hand, IMHO, because: 1. We like to provide convenience aids, and Emacs is good for composing text and can easily retrieve info about the session. 2. Emacs Dev is proud of the fact that Emacs can itself be used as a mail client, so it has warped the reporting procedure/dialog into one about sending mail using Emacs. It's all well and good to have Emacs _be able_ to help users compose their report and send it. But that possibility should not be taken as a necessity, or end up as a restriction on the user. Write, copy, paste, and send (from an external client) should at least be MENTIONED, front and center, in the instructions/help shown by `report-emacs-bug' as a primary way of reporting a bug. Today, it is not.