From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [ Date: Tue, 26 Nov 2019 08:24:30 -0800 (PST) Message-ID: <5e049504-3fa3-4b89-a506-c16fd05d0e79@default> References: <20191117113054.49837.qmail@mail.muc.de> <87pnhq7mxg.fsf@gnus.org> <87bltaz9g4.fsf@telefonica.net> <834kz25qp9.fsf@gnu.org> <87y2wexsv1.fsf@telefonica.net> <20191118175639.08d02820@jabberwock.cb.piermont.com> <874kz0pa9y.fsf@gnus.org> <87sgmjyn60.fsf@gmx.de> <87imnezyt5.fsf@gmx.de> <481a1f16-d661-0f96-2f45-3d5ec9c1132e@yandex.ru> <871ru0t7p8.fsf@gnus.org> <7a7f8955-ec5f-4e1e-b258-19379588516a@default> <86sgmftq1m.fsf@zoho.eu> <87a78k8mka.fsf@osv.gnss.ru> <868so4bdsi.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="39035"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Richard Stallman , Emanuel Berg , Emacs developers To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 26 17:26:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iZdfs-000A0o-Gm for ged-emacs-devel@m.gmane.org; Tue, 26 Nov 2019 17:26:48 +0100 Original-Received: from localhost ([::1]:56806 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZdfr-0004BS-CB for ged-emacs-devel@m.gmane.org; Tue, 26 Nov 2019 11:26:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36584) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZdfj-0004B2-8s for emacs-devel@gnu.org; Tue, 26 Nov 2019 11:26:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZdfh-0004vA-Ld for emacs-devel@gnu.org; Tue, 26 Nov 2019 11:26:38 -0500 Original-Received: from userp2130.oracle.com ([156.151.31.86]:39298) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZdfh-0004u2-9W; Tue, 26 Nov 2019 11:26:37 -0500 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAQGJHrd147653; Tue, 26 Nov 2019 16:26:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=doQasxVes6NM/l540AzNVUkIIYAvz81nlOmdgAhAcOY=; b=oafBk13aA7ioq5+jJSIVFAMEryPGXbS0A7zHnUagzHRlSsvnpqGl1Ff+3vtNrM0US03Z wy3Uwa7TuOQ8eeeo2VS+bPcaqcNDZDW4gkKdlMQZaMQJEkz5z/0AszNeMTOkesP/6bRl h+wM9oJiYFolB3mXeezHySSYzo5SDzNMgGpwiA4kXwUTMR1m1IRSe1DeNICdYCsOccaQ MvKQCmwaiIW1f+tVA6DYahFY8Fgy0hntHlS8rmy5S9AzB1Gmil266xwa+iwZbDEyhP0V Zwi5PMZKR0uKAz80T9VwK31TGBh5wKfwgWS4cBzkPTznQViP49BQQch3Skpn/456kB6S Gw== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2wev6u7yg1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Nov 2019 16:26:35 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id xAQGJJlc112806; Tue, 26 Nov 2019 16:24:34 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2wh0rcka9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Nov 2019 16:24:34 +0000 Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id xAQGOVNJ006096; Tue, 26 Nov 2019 16:24:31 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4927.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911260139 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9453 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911260139 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 156.151.31.86 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:242738 Archived-At: > > 2. There are individual commands to insert each of> the various > fields, so you can easily include > > any that you don't choose to include by default. > > Most are bound to keys with prefix `C-o'. >=20 > That seems like more typing (and remembering) than I'd prefer. If we > want to do something like this, my ideal would be closer to how magit > handles chunks: 'n' to go to next, 'k' to kill it. #1, which you didn't quote, was the main thing. The idea is that a user will typically want the same fields to be included/excluded for her bug reports. In that case there's rarely any need to do anything (hit a key to include, or kill text to exclude it). The keys to include specific sections are available for the rare case when you might want to include something you generally exclude (via the option). And `C-h m' tells you about the keys - there's really nothing to remember. Using such a key would be relatively rare, in which case `C-h m' is your friend. > To elaborate, let's say I move point outside the "body text" part of > the bug report, on top of the auto generated data. Here, the current > "block" (as detailed above: features, load-path-shadows, major-mode, > etc.) gets highlighted, and the keys no longer does > self-insert-comand, but instead the commands: >=20 > 'n' move to next block > 'p' move to previous block > 'e' edit current block (make "block" into regular text, disabling > commands) > 'k' kill current block >=20 > Even better if you see a help text in the minibuffer when point is on > these blocks. >=20 > Just an idea. Not sure if it's worth implementing, but I think it > would be useful. Good. All ideas are helpful. I think it's generally better to let users define the typical, general behavior they want. That's better than always including everything (a hard-coding the behavior) and then giving users ways to navigate and kill included text. Why make users do that? IOW, instead of making users kill the same kind of text over and over, each time they file a bug, let them choose their own preferred (default) reporting behavior. The default value of the option I provided does include everything (all fields) - we ask for it for a reason. But a user can provide her own default behavior by customizing the option. For example, a user might change the default behavior, to include only the Emacs _version_. Because there's a command (and key) for each section, she can easily override her default behavior whenever including something more makes sense to her. Because I split the included text into separate pieces (categories/fields), the code is a bit cleaner, and users have better control over the behavior. Likewise, any code that wants to tweak or make use of the basic code.