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: Remove "Recent messages" from `M-x report-emacs-bug' Date: Wed, 11 May 2016 07:44:48 -0700 (PDT) Message-ID: <03aa6991-05db-42d8-93cb-9b45ece07436@default> References: <<<87k2j3jq28.fsf@gnus.org>> <<6ccbf505-5818-432b-98fa-0733930be2e7@default>> <>> <<3ad08202-3529-4613-8f78-ef10b3abb9e2@default>> <> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1462977946 680 80.91.229.3 (11 May 2016 14:45:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 May 2016 14:45:46 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org To: rms@gnu.org, Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 11 16:45:34 2016 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 1b0VOH-0007t1-NQ for ged-emacs-devel@m.gmane.org; Wed, 11 May 2016 16:45:33 +0200 Original-Received: from localhost ([::1]:52683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0VOG-0003jR-So for ged-emacs-devel@m.gmane.org; Wed, 11 May 2016 10:45:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0VNi-0002qJ-Kv for emacs-devel@gnu.org; Wed, 11 May 2016 10:44:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0VNe-0004rk-9e for emacs-devel@gnu.org; Wed, 11 May 2016 10:44:57 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:18172) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0VNe-0004rU-1E; Wed, 11 May 2016 10:44:54 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4BEipZX029674 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2016 14:44:51 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u4BEioQ8030888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 May 2016 14:44:51 GMT Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4BEinbr030699; Wed, 11 May 2016 14:44:50 GMT In-Reply-To: <> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:203783 Archived-At: > > Asking is not bad, as a default behavior. But a user who is asked > > should be able, while responding, to state whether s?he wants to > > continue to be asked for subsequent bug reports. >=20 > Why? The answer won't be the same each time. It depends on what > you're doing. The answer _might_ be the same each time. Or it might be the same _most_ times. The point is to give a user the chance to _decide whether_ to be asked each time. Some users might not want to be asked each time. A user can set personal default behavior. A user can override that behavior for any given bug report (e.g., if s?he thinks that some kind of info is important to that report). These latter two features are what I provided in the slight extension to emacsbug.el: (1) Let users customize what the default behavior is, for them. (2) Let users override this for any given report, by providing commands that insert particular kinds of info. What you added to the mix was the suggestion to ask users what they want to do in this regard, when they submit a report. What I added to your suggestion is to let users do that AND let them choose whether to (a) apply their answer also to future reports or (b) be asked anew each time.