From unknown Sat Aug 16 18:16:42 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#20063 <20063@debbugs.gnu.org> To: bug#20063 <20063@debbugs.gnu.org> Subject: Status: 24.4: read-from-minibuffer improperly setting hist parameter Reply-To: bug#20063 <20063@debbugs.gnu.org> Date: Sun, 17 Aug 2025 01:16:42 +0000 retitle 20063 24.4: read-from-minibuffer improperly setting hist parameter reassign 20063 emacs submitter 20063 Boruch Baum severity 20063 minor thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 08 18:27:10 2015 Received: (at submit) by debbugs.gnu.org; 8 Mar 2015 22:27:10 +0000 Received: from localhost ([127.0.0.1]:39841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUjfC-0006Y8-1N for submit@debbugs.gnu.org; Sun, 08 Mar 2015 18:27:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54566) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUjf9-0006Xs-QT for submit@debbugs.gnu.org; Sun, 08 Mar 2015 18:27:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUjf3-0005Ih-DN for submit@debbugs.gnu.org; Sun, 08 Mar 2015 18:27:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:53023) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUjf3-0005Id-A0 for submit@debbugs.gnu.org; Sun, 08 Mar 2015 18:27:01 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUjew-0001gF-P5 for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 18:27:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUjeq-0005C0-HX for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 18:26:54 -0400 Received: from mout.gmx.net ([212.227.17.21]:52805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUjeq-0005Bw-8J for bug-gnu-emacs@gnu.org; Sun, 08 Mar 2015 18:26:48 -0400 Received: from [192.168.1.9] ([96.232.130.59]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MS0c2-1Y2e9E20lO-00TGWt for ; Sun, 08 Mar 2015 23:26:47 +0100 Message-ID: <54FCCC63.5080202@gmx.com> Date: Sun, 08 Mar 2015 18:25:39 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.4: read-from-minibuffer improperly setting hist parameter OpenPGP: url=hkp://keys.gnupg.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a7MgtBepkJEmEoPlCfULCf7fDe6xBcBqj" X-Provags-ID: V03:K0:xiDrcipFn/qlBBeSu1VUidbpQgA8OqLXr63GGwbvGUMWI0e1KwW lR3HY2dyP5q1d1O9ON/ukg9Rcdq8l2YcRH/yRRxxTMzimNACcyzNrFmiWT29yR3lLwIExfO 7fZln5FU9VucnkiulXF8133PT9xeHfRbPm9FtSLRVGuabN7MoxzmHdmT584M6ie358TmPV1 w1egWa7byNG7+BVp9LkRA== X-UI-Out-Filterresults: notjunk:1; X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.1 (----) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a7MgtBepkJEmEoPlCfULCf7fDe6xBcBqj Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This started out as a bug report for function `toggle-option' in file toggle-option.el. That function takes a user-defined list of options through which the user can scroll in the minibuffer. However, the scrolling only operates in the forward direction (using the down-arrow key); When scrolling in the reverse direction (using the up-arrow key), one gets elements from some other history list, which are mostly items invalid for the function called, and in fact are correctly rejected by the function (toggle-option) if one selects them. Function `toggle-option' calls `completing-read', without providing parameters REQUIRE-MATCH or HIST. `completing-read' calls `completing-read-default' in `minibuffer.el'. `completing-read-default' calls `read-from-minibuffer' in `minibuf.c'. There, on line 974 of `minibuf.c:' if (NILP (histvar)) histvar =3D Qminibuffer_history; If I understand this correctly, this says that even if the caller explicitly says that there should be no history used (condition nil), the Qminibuffer_history should be used anyway. Correcting this looks like it would solve other bugs reported (eg. bug #19877). BTW, I fiddled with function `toggle-option', and even when all the optional parameters are explicitly passed with nil values, the behavior remains the same. BTBTW, `read-from-minibuffer' calls `read-minibuf' which calls `read_minibuf_noninteractive' (line 223 in minibuf.c), which asks for parameters it does not use: map, initial, backup_n, histvar, histpos, allow_props, and inherit_input_method (BTBTBTW, courtesy of the spelling police, unless 'default' is a reserved word, parameter 'defalt' might properly be refactored `default'). Finally, my two cents are that when functions ask for parameter COLLECTION to scroll through, that scrolling should wrap-around, and not report an error when reaching the first or final entry. --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --a7MgtBepkJEmEoPlCfULCf7fDe6xBcBqj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU/MxjAAoJEDvrUfDmCx9LtMAP/1B6rUTRNzUrzofYtNFHGA9p 1mBY11HnLmu88Jk2GJ+vo313WyXU8PlkWK/1U/niu9FFxIwULsvwvVO/AYsqIVxh 3ogx5rghW1GDFD+MxYOetdQ+/7Vghbpcq7D/RieC5wG8cUPgicS3ArXszj5i2eP0 0ls1lrURVOxjI6sbCbH9gqDmzHCOphHoBWKWNWKXYs/PuqUjyKQCTdTSbJz1qmyK qlfLPSZj/TS2yYuoGhQBiwCQ2Yob3w0KHrp4ilaBH9eknBdq8Z5RNjQhtKUvgbOs m8MLAYHzpcJingKG6iGV27By8KE5NM75YOWph8ObC36AbotmXqXzPb6uq3PBkfFY 6S1CZnnlGE4bzyZ3wK+WlaPOUNRQSGbpex6m718BhHvc/91SJg6fmYo2d/Snz48U E1e2orJ0cEhMyW94mZP3sC259Js4oi0cmKGRiNy6nv28kE2JFjwXll2yEsvhGK1f 1VF468EAEDs8jXdKVpF6hsKvNC9tLD3MyxlJGeKVtjJF6XbPyWt2MG5MV2QNl+3w Sijm85nngj4E55HaxaJScB2xH3wMdM3+9Gx3uYmODW1JW8i48OVM4y0Ww6zE9jyg rCKgjjf43Pd0z22G8LRKRQVu+g4Th3QzYes6uDmA4pg1fIqJlplZnvY1B/ezBxme 8NSLYGNZrKgo/dBYASKt =WRLe -----END PGP SIGNATURE----- --a7MgtBepkJEmEoPlCfULCf7fDe6xBcBqj-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 08 21:09:00 2015 Received: (at 20063) by debbugs.gnu.org; 9 Mar 2015 01:09:00 +0000 Received: from localhost ([127.0.0.1]:39897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUmBo-0003lw-1g for submit@debbugs.gnu.org; Sun, 08 Mar 2015 21:09:00 -0400 Received: from fencepost.gnu.org ([208.118.235.10]:50787 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUmBm-0003lo-7H for 20063@debbugs.gnu.org; Sun, 08 Mar 2015 21:08:58 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1YUmBl-0003SD-Is; Sun, 08 Mar 2015 21:08:57 -0400 From: Glenn Morris To: Boruch Baum Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <54FCCC63.5080202@gmx.com> X-Spook: smuggle Reno Fedayeen crypto anarchy colonel South Africa X-Ran: LJ-e`V3-';12"|]O|?lJWCqDp\{1>Hf&rnJ/ (Boruch Baum's message of "Sun, 08 Mar 2015 18:25:39 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: 20063 Cc: 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) Boruch Baum wrote: > Function `toggle-option' calls `completing-read', without providing > parameters REQUIRE-MATCH or HIST. `completing-read' calls > `completing-read-default' in `minibuffer.el'. `completing-read-default' > calls `read-from-minibuffer' in `minibuf.c'. There, on line 974 of > `minibuf.c:' > > if (NILP (histvar)) > histvar = Qminibuffer_history; > > If I understand this correctly, this says that even if the caller > explicitly says that there should be no history used (condition nil), > the Qminibuffer_history should be used anyway. Nil means use the default history list. Eg see "Minibuffer History" in the elisp manual: If you don't specify HISTORY, then the default history list `minibuffer-history' is used. I don't see a bug here, other than perhaps the doc of completing-read could stand to be more explicit, like the elisp manual is. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 09 08:06:27 2015 Received: (at 20063) by debbugs.gnu.org; 9 Mar 2015 12:06:27 +0000 Received: from localhost ([127.0.0.1]:40185 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUwS2-0007uM-Pk for submit@debbugs.gnu.org; Mon, 09 Mar 2015 08:06:27 -0400 Received: from mout.gmx.net ([212.227.17.20]:59547) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YUwS0-0007u6-91 for 20063@debbugs.gnu.org; Mon, 09 Mar 2015 08:06:25 -0400 Received: from [192.168.1.5] ([96.232.130.59]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXEs5-1XyszX0Aon-00WIJT; Mon, 09 Mar 2015 13:06:18 +0100 Message-ID: <54FD8C77.7040208@gmx.com> Date: Mon, 09 Mar 2015 08:05:11 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Glenn Morris Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <54FCCC63.5080202@gmx.com> In-Reply-To: OpenPGP: url=hkp://keys.gnupg.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="x6JRUCo5uFQSOjFcw6fB1nN8jI7DUvn4r" X-Provags-ID: V03:K0:x0Yi8xKfRujDviUMYP08EWJzpUi7vQDiCw/tzcOb8fQF20Poqcq nelcsfbS8G9Xqevamp/q2zDg6fbhCXl80LU98kaSExOlkn06f0zL3du7H03VdMaZCzV3/NU g3+Iq6gaARzeUaci0AjLega97xfPLq643ejw5j8ipWZcPerSplI2oizT52hGK7I8A3wRL4f kh/AeLSRqlxRrqPReX3Pg== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20063 Cc: 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x6JRUCo5uFQSOjFcw6fB1nN8jI7DUvn4r Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Three reasons I think this should be considered a bug, and changed - two from a programmer's perspective, and one from a user's perspective. For both, consider the cases of functions `toggle-option' (this bug report) and `highlight-regexp' (bug #19877). 1] From a programmer's perspective, forcing a HIST when the programmer asks for COLLECTION =3D !nil and HIST =3D nil, creates a conflict when parameter REQUIRE-MATCH is set to `t', because the mini-buffer will offer entries, from HIST, that are not in COLLECTION, and those entries will then just be rejected due to REQUIRE-MATCH. 2] From a programmer's perspective, there are four legitimate combinations of COLLECTION and HIST, and the current state denies a programmer the freedom to offer a specific COLLECTION without some general HIST. 3] From a user's perspective (and this is how I came across both instances of this issue), I don't want invalid or nonsense options being presented to me by emacs. They just confuse, invite unwanted outcomes, and delay finishing the task at hand. In the case of `toggle-option', the current situation has the mini-buffer offering the user options that, should the user select, will be rejected as invalid by the mini-buffer. In the case of `highlight-regexp', the choices that the mini-buffer offer from HIST are accepted, but are undesirable, lead to confusion in selection, and confusion in navigating amongst the desirable elements, ie. those in COLLECTION. On 03/08/2015 09:08 PM, Glenn Morris wrote: > Boruch Baum wrote: >=20 >> Function `toggle-option' calls `completing-read', without providing >> parameters REQUIRE-MATCH or HIST. `completing-read' calls >> `completing-read-default' in `minibuffer.el'. `completing-read-default= ' >> calls `read-from-minibuffer' in `minibuf.c'. There, on line 974 of >> `minibuf.c:' >> >> if (NILP (histvar)) >> histvar =3D Qminibuffer_history; >> >> If I understand this correctly, this says that even if the caller >> explicitly says that there should be no history used (condition nil), >> the Qminibuffer_history should be used anyway. >=20 > Nil means use the default history list. Eg see "Minibuffer History" in > the elisp manual: >=20 > If you don't specify HISTORY, then the default history list > `minibuffer-history' is used. >=20 > I don't see a bug here, other than perhaps the doc of completing-read > could stand to be more explicit, like the elisp manual is. >=20 --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --x6JRUCo5uFQSOjFcw6fB1nN8jI7DUvn4r Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU/YyFAAoJEDvrUfDmCx9Lh5cP/R5M3YtmMQ0d5YHO0wDn+Php mNqELBSiIUPYxB5njivLs8vERRcj0XtugEHcWoDa6LXBAaUZYI1h3U2Yecr3x2sF ELZ8h6ci2TwvN8Dx4Uwwg4x3o7rwMGPpXpFl2Yh4MmjivPpK3IpvqZZfCcCO3ej5 zLWzqY5B5iyOivyXFU7O8NKGEPNZOzSlXPJbF3XWmBmQ0856yKpsfn74Q+mSz6lu E3RRqvQI37OtOJtRMf7Pbcs6NAB6gqwmEiWoo6HBpwKm7MH+XLmFcJG7NYSpMHEM Dj5LCoNy1bGpbkSWLdrOe4Q6RoL2Dkhj2TH749MThZliWSixU9mTM8JlPayL8pF3 EnywbrHX8ziH5QBNQ2UwH8zPWg4H7nEa+0psqvzV6nAT3rAwAwf5Q/7/ilkI4Fvw xtx2zxFobABEXorxkQuV1ImqAdjGOoH15YqS5bCaYQHAyDUn/3QOzTfRaosPuClg 0KQhRXcDJPJOqus7gWx2C24FueDrXw4ih1tmV34+hL6wjVu0AtXPDNhk2oUyH07b Y18CvUnoBFk71CyBrMIkJyVAwHpfJ/qVw2Qt4qWFJFrCuLXsyQ15r9Ks6bVNZ/gg dhDcBD/EXhZo1Vz+DdfkLxzdxWMHeMZM7XLD+avN6fS7YvIG8JbG9+Xbng1OYes4 tpJkFB+Jg/c+ODgSmF33 =FVcx -----END PGP SIGNATURE----- --x6JRUCo5uFQSOjFcw6fB1nN8jI7DUvn4r-- From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 09 14:15:00 2015 Received: (at 20063) by debbugs.gnu.org; 9 Mar 2015 18:15:00 +0000 Received: from localhost ([127.0.0.1]:40909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YV2Ci-0000fb-GA for submit@debbugs.gnu.org; Mon, 09 Mar 2015 14:15:00 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:33166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YV2Cg-0000fT-MF for 20063@debbugs.gnu.org; Mon, 09 Mar 2015 14:14:59 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 6EF9285195; Mon, 9 Mar 2015 14:14:58 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 8FE7B1E5B8C; Mon, 9 Mar 2015 14:14:34 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 74B76B4130; Mon, 9 Mar 2015 14:14:34 -0400 (EDT) From: Stefan Monnier To: Boruch Baum Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Message-ID: References: <54FCCC63.5080202@gmx.com> <54FD8C77.7040208@gmx.com> Date: Mon, 09 Mar 2015 14:14:34 -0400 In-Reply-To: <54FD8C77.7040208@gmx.com> (Boruch Baum's message of "Mon, 09 Mar 2015 08:05:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > 1] From a programmer's perspective, forcing a HIST when the programmer > asks for COLLECTION = !nil and HIST = nil, creates a conflict when > parameter REQUIRE-MATCH is set to `t', because the mini-buffer will > offer entries, from HIST, that are not in COLLECTION, and those entries > will then just be rejected due to REQUIRE-MATCH. That is indeed a problem, but it is more general than the case of HIST=nil, since even if HIST is non-nil the history may contain entries which are not valid according to COLLECTION. So what we need to do is to filter out those entries dynamically. > 2] From a programmer's perspective, there are four legitimate > combinations of COLLECTION and HIST, and the current state denies a > programmer the freedom to offer a specific COLLECTION without some > general HIST. Actually, IIRC a value of t for HIST does provide the option of "no history". Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 10 11:34:57 2015 Received: (at 20063) by debbugs.gnu.org; 10 Mar 2015 15:34:57 +0000 Received: from localhost ([127.0.0.1]:41850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVMBM-0000wK-Pi for submit@debbugs.gnu.org; Tue, 10 Mar 2015 11:34:57 -0400 Received: from mout.gmx.net ([212.227.15.18]:60265) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVMBL-0000w4-00 for 20063@debbugs.gnu.org; Tue, 10 Mar 2015 11:34:55 -0400 Received: from [192.168.1.9] ([96.232.130.59]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Meh8S-1Y7EgX3hJg-00OGAX; Tue, 10 Mar 2015 16:34:46 +0100 Message-ID: <54FF0EE8.5040107@gmx.com> Date: Tue, 10 Mar 2015 11:34:00 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <54FCCC63.5080202@gmx.com> <54FD8C77.7040208@gmx.com> In-Reply-To: OpenPGP: url=hkp://keys.gnupg.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mJWD4dqqHEQVhEkD1prE0gUckG4QsCAd3" X-Provags-ID: V03:K0:w0qhoXIxSFLUIumKExs57qRtEjm1DRRUUHaLxm5yUE2pC+1W/xr QeVuvNpZk0VoXnIBgzbpVc4PW05kVPIRgO1Qh6W2Quo3u5j48d2TPzcSGEUPgKApMPNGrDO Av7un20McUyWxZRzOveO0w3qaYXQKLWeAmf7QCaBADNYkMNCuX7LXh8VGNaquzXYJhDG2EP /2LfeS1Ib9qZ92Y7Ilq3A== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mJWD4dqqHEQVhEkD1prE0gUckG4QsCAd3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/09/2015 02:14 PM, Stefan Monnier wrote: >> 1] From a programmer's perspective, forcing a HIST when the programmer= >> asks for COLLECTION =3D !nil and HIST =3D nil, creates a conflict when= >> parameter REQUIRE-MATCH is set to `t', because the mini-buffer will >> offer entries, from HIST, that are not in COLLECTION, and those entrie= s >> will then just be rejected due to REQUIRE-MATCH. >=20 > That is indeed a problem, but it is more general than the case of > HIST=3Dnil, since even if HIST is non-nil the history may contain entri= es > which are not valid according to COLLECTION. >=20 > So what we need to do is to filter out those entries dynamically. Yes, if you mean once, at the time the function is invoked; but the benefit of this to the end-user is very limited, and has a downside if done simply. Once REQUIRE-MATCH=3Dt, nothing but elements of COLLECTION will ever be accepted, so `concat'-ing the filtered elements of HIST would present only legitimate options, in the sequence most recently used, but with potentially a lot of duplicate entries. Using `add-to-list', starting with an empty list would avoid the duplications and present the elements in sequence most-recently-used. >> 2] From a programmer's perspective, there are four legitimate >> combinations of COLLECTION and HIST, and the current state denies a >> programmer the freedom to offer a specific COLLECTION without some >> general HIST. >=20 > Actually, IIRC a value of t for HIST I don't see that in the v24.4 documentation for `completing-read' or 'read-from-minibuffer'. Both descriptions are a bit vague, saying "... if non-nil ... It can be a symbol, which is the history list variable to use, or it can be a cons cell (HISTVAR . HISTPOS) ...". It would be clearer to change "It can be" to "Otherwise it must be either" > does provide the option of "no history". Which brings us full-circle to line 974 of `minibuf.c' --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --mJWD4dqqHEQVhEkD1prE0gUckG4QsCAd3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU/w7oAAoJEDvrUfDmCx9LNkcP/imWoM/pnTw+skNlHnxQJdi2 v8NquOe0PGD0mPCWHgNgsOYIbfmgEdUj2O4sTEeVuCUkWOFReRQNa+7C2U2m+cGF 9TsMcToFmWC7wGZ3uO2MLwQuHCyPGw7wvw0QuO2M11RuMl22g6yowLykHl56odMD IYopOklbIyUIUx3ITxuKtHk5GxM135jwoGtS3pgz4CPgbFMEapiv3y4qr+ppiZIB Dyt7Pgif2vqHxdz57fb/vb3yTQyXh3y2P9EoMV2OXzSjyGAfHhoqgPeft/Kz58pU IekRbxDqlU9atB6v+R9GZ0mjz+65658l5X2glRiyBhuCotvPvjev4UIcYy0IYf3k 4nv7lPysDYkCkmKar+8mgaVQawPNbpEIg5RwKTSVgkFuXMjZVmAkbFSqSMfyjOgo 7X93dbaZmFxmy46ME9qDdHcIlzon7Vj9sLw1x5zBWV2/vRmDguPYTFzt68SCbfTV 4XLRV1g8u+pyHnOPIwv1wTsXj44AJo/ZbMmjQNaPTDxlclNyZ8LJrqsUVlngRHNF wXmX2I/Tq98JO4kR2cmy97Ssv3dWiXx0cKLztIJC9mnioLsRDKtUcn7MdsNw8C/M jlkVTR6923NlRLA7rZVbAsdrKuyyoUKt0jGC7UMPIwZHcg4hsTjFFL9j3W3rRmkB d3vbugF8yeDkLWgrpkZs =5DiF -----END PGP SIGNATURE----- --mJWD4dqqHEQVhEkD1prE0gUckG4QsCAd3-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 10:09:12 2015 Received: (at 20063) by debbugs.gnu.org; 11 Mar 2015 14:09:12 +0000 Received: from localhost ([127.0.0.1]:42876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVhJv-0007y9-MU for submit@debbugs.gnu.org; Wed, 11 Mar 2015 10:09:12 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:9190) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVhJs-0007xr-EO for 20063@debbugs.gnu.org; Wed, 11 Mar 2015 10:09:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsTAPOG1lRLd/Fx/2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzAEEhQYDSSIOAjOIwEBAQEGAQEBAR6PIFgHGIQSBZR8hGOFSYpKgUUihAoigTOBQAEBAQ X-IPAS-Result: ArsTAPOG1lRLd/Fx/2dsb2JhbABbgwaDX4VTwGUEAgKBDUQBAQEBAQF8hA0BBAFWIwULCzAEEhQYDSSIOAjOIwEBAQEGAQEBAR6PIFgHGIQSBZR8hGOFSYpKgUUihAoigTOBQAEBAQ X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="113276498" Received: from 75-119-241-113.dsl.teksavvy.com (HELO pastel.home) ([75.119.241.113]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Mar 2015 10:09:02 -0400 Received: by pastel.home (Postfix, from userid 20848) id 61046FEF; Wed, 11 Mar 2015 10:09:02 -0400 (EDT) From: Stefan Monnier To: Boruch Baum Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Message-ID: References: <54FCCC63.5080202@gmx.com> <54FD8C77.7040208@gmx.com> <54FF0EE8.5040107@gmx.com> Date: Wed, 11 Mar 2015 10:09:02 -0400 In-Reply-To: <54FF0EE8.5040107@gmx.com> (Boruch Baum's message of "Tue, 10 Mar 2015 11:34:00 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> That is indeed a problem, but it is more general than the case of >> HIST=nil, since even if HIST is non-nil the history may contain entries >> which are not valid according to COLLECTION. >> So what we need to do is to filter out those entries dynamically. > Yes, if you mean once, at the time the function is invoked; No, I was thinking of doing it on-the-fly when navigating in the history. > but the benefit of this to the end-user is very limited, and has > a downside if done simply. If the benefit is limited, it means the problem you mention is correspondingly minor. > Once REQUIRE-MATCH=t, nothing but elements of COLLECTION will ever be > accepted, so `concat'-ing the filtered elements of HIST would present > only legitimate options, in the sequence most recently used, but with > potentially a lot of duplicate entries. I'm not sure exactly what you mean here, but I suspect you assume COLLECTION to be finite and small. > Using `add-to-list', starting with an empty list would avoid > the duplications and present the elements in sequence > most-recently-used. Duplicate elements in the history are yet again orthogonal. You probably want to set history-delete-duplicates to t. >> Actually, IIRC a value of t for HIST > I don't see that in the v24.4 documentation for `completing-read' or Indeed, it's not documented. It's basically a side effect of t holding a non-list value, which we've tried to make work in order for read-password to behave properly (i.e. not have history since that would be a security problem). >> does provide the option of "no history". > Which brings us full-circle to line 974 of `minibuf.c' I don't understand this, since this code checks for a nil value, not a t value. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 11:44:07 2015 Received: (at 20063) by debbugs.gnu.org; 11 Mar 2015 15:44:07 +0000 Received: from localhost ([127.0.0.1]:42937 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVinm-00021r-LF for submit@debbugs.gnu.org; Wed, 11 Mar 2015 11:44:07 -0400 Received: from mout.gmx.net ([212.227.15.18]:57737) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVink-00021F-OX for 20063@debbugs.gnu.org; Wed, 11 Mar 2015 11:44:05 -0400 Received: from [192.168.1.7] ([96.232.130.59]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZzKf-1ZHPTY012j-00lmsO; Wed, 11 Mar 2015 16:43:53 +0100 Message-ID: <5500628F.3020405@gmx.com> Date: Wed, 11 Mar 2015 11:43:11 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <54FCCC63.5080202@gmx.com> <54FD8C77.7040208@gmx.com> <54FF0EE8.5040107@gmx.com> In-Reply-To: OpenPGP: url=hkp://keys.gnupg.net Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HwIdoHWxeemJ8H8mFc62t51RFEG0N9RwF" X-Provags-ID: V03:K0:hxSGFb+rScsexIo//9fIgOipoUKyOAvasKUz5WVhBUsLyTl/KvN ztIqejMAuELDc/v/vb3SfuVIEDOFYzoniZQSh9+1M02PoZVGdb4XdFsPe/lMnfSRBQsr+T0 TW+FrA6XC+21wRouYatBiCqwsceX+Dh7MTfCdZHTeDwE14x7uR8qGm3600XoT4LWCOsjsCn U4PUUJwUj5UoHLkvrvnSQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HwIdoHWxeemJ8H8mFc62t51RFEG0N9RwF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/11/2015 10:09 AM, Stefan Monnier wrote: >> but the benefit of this to the end-user is very limited, and has >> a downside if done simply. >=20 > If the benefit is limited, it means the problem you mention is > correspondingly minor. I was referring to the benefit of your idea to filter out !COLLECTION elements dynamically, not the bug that offers the user nonsense or unacceptable HIST elements in the mini-buffer. >> Once REQUIRE-MATCH=3Dt, nothing but elements of COLLECTION will ever b= e >> accepted, so `concat'-ing the filtered elements of HIST would present >> only legitimate options, in the sequence most recently used, but with >> potentially a lot of duplicate entries. >=20 > I'm not sure exactly what you mean here, but I suspect you assume > COLLECTION to be finite and small. The characterization of 'finite' isn't an assumption; it's a requirement - how could one REQUIRE-MATCH=3Dt against a COLLECTION of infinite size? OTOH, your characterization of 'small' (and the meaning of 'small' is always difficult) isn't an assumption of mine, but, who knows, it may have been an assumption of the designers of the mini-buffer functions. >> Using `add-to-list', starting with an empty list would avoid >> the duplications and present the elements in sequence >> most-recently-used. >=20 > Duplicate elements in the history are yet again orthogonal. > You probably want to set history-delete-duplicates to t. I wasn't advising what I want; I was trying to be helpful by pointing out a problem in the mini-buffer function. A user may normally want to retain duplicates in her general command history as a record of past activity, but not have those duplicates appear in mini-buffer selections that have REQUIRE-MATCH=3Dt. To illustrate, imagine yourself, as a user, scrolling back through a minbuffer history in order to see what your legitimate REQUIRE-MATCH=3Dt options are. When would you ever want duplicates to appear in your scrolling? It would only delay your ability to see all your options. >>> does provide the option of "no history". >> Which brings us full-circle to line 974 of `minibuf.c' >=20 > I don't understand this, since this code checks for a nil value, not > a t value. My report never discussed the undocumented HIST=3Dt option; that was your= contribution. The documentation does provide for HIST=3Dnil, which -IS- a= central element of the bug report. We've been covering a lot of ground, so its understandable that we may have started straying from the original bug report (see there), but that also can be useful and constructive if it helps inform a resolution. This is especially true since we're discussing very widely used functions= =2E It may be helpful to look at the issue from two perspectives: 1] 'bottom-up', starting from `read-from-minibuffer'. This would be the theoretical perspective; 2] 'top-down', starting from functions such as `toggle-option' and `highlight-regexp'. This would be the practical perspective. --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --HwIdoHWxeemJ8H8mFc62t51RFEG0N9RwF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVAGKPAAoJEDvrUfDmCx9LQRYQAJ4OkajYM14JfoCZhVgNUmkz JMVoUkprdphXj+lvH7oGzYX6LM9hYAANDiGMPwc8JqEP67QDhrniXcDUGYXXfTMW /ESPqSeYxQF3atM5ZSqNTYZC87dx+Pclj/qfBlwqmAdqsPgo+Y542eC+Z9sCaG4E qfzXEbYkVICDLWYPFi/ik/7ekGKlbOUIHOVYQDF3MroD/dCi1zMy5Pa8i2wYsCvr w8vhN0kyO77G+lE7wdO7gtR5QEycTdkwK/tckoNhh128e8F0I2Q6BoCTwG45E5EI GLT1w0hKMFOXYtieTwbdh1jbFtbK1dHBDfKP3DYomJQ9VU8JsI0oKnGlANNVQE7t KsDAGv29mvXJDJxpHIrdR9t7kjpDRfABKtgmsIP11UsH9qnzf2N+xAzelHx6XS7b XTor+c/GHduIdCDMYtooFLwFz98tCxFru54bG1+RTlDwXPQ7wKU4Ih3TQIjwiDIV 7sdPPiva9VoZoJjws1JpOyAIs+iaZ03/F3j4So7eZhWKlhUUi1W4v8SqmrmMujba ENTwd/Rer/LfX8IwrcT5NS41UPzrNfjh3/jUHbKHG52hGelnfkdwHgcjj2K0ph9/ aOAZJuzhFo3qYgbWI3ZMleSf7LcCfAZnplfaFmeHF8/R0/txXTPClihje+cycIU0 hR6/dxyvGdaLM8gq6lnJ =IKDl -----END PGP SIGNATURE----- --HwIdoHWxeemJ8H8mFc62t51RFEG0N9RwF-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 11 15:19:53 2015 Received: (at 20063) by debbugs.gnu.org; 11 Mar 2015 19:19:53 +0000 Received: from localhost ([127.0.0.1]:43154 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVmAa-0002L3-Pr for submit@debbugs.gnu.org; Wed, 11 Mar 2015 15:19:53 -0400 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34460) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YVmAY-0002Ku-Ro for 20063@debbugs.gnu.org; Wed, 11 Mar 2015 15:19:51 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 12B9385F04; Wed, 11 Mar 2015 15:19:48 -0400 (EDT) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 752F31E5B74; Wed, 11 Mar 2015 15:19:23 -0400 (EDT) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 49E65B4102; Wed, 11 Mar 2015 15:19:23 -0400 (EDT) From: Stefan Monnier To: Boruch Baum Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Message-ID: References: <54FCCC63.5080202@gmx.com> <54FD8C77.7040208@gmx.com> <54FF0EE8.5040107@gmx.com> <5500628F.3020405@gmx.com> Date: Wed, 11 Mar 2015 15:19:22 -0400 In-Reply-To: <5500628F.3020405@gmx.com> (Boruch Baum's message of "Wed, 11 Mar 2015 11:43:11 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >> If the benefit is limited, it means the problem you mention is >> correspondingly minor. > I was referring to the benefit of your idea to filter out !COLLECTION > elements dynamically, not the bug that offers the user nonsense or > unacceptable HIST elements in the mini-buffer. One of the benefits of filtering out elements not in COLLECTION is to avoid providing "offer[ing] the user nonsense or unacceptable HIST elements in the mini-buffer". So if you think the benefit is limited, it necessarily means that "the bug" is correspondingly minor. FWIW, I do think it's indeed minor (which is why I haven't written this filtering yet, even though I've had it in my "wishlist" for quite a while). > - how could one REQUIRE-MATCH=t against a COLLECTION of infinite size? Theoretical answer: let COLLECTION be the set of strings that represent a natural number. It's infinite, and it makes sense (for example in read-number) to use REQUIRE-MATCH=t with it. Practical answer: read a file name in order to delete it. The corresponding COLLECTION is as good as infinite (especially if you include remote hosts via Tramp), and you do want to use REQUIRE-MATCH=t since you don't need to let the user delete a non-existing file. > A user may normally want to retain duplicates in her general command > history as a record of past activity, but not have those duplicates > appear in mini-buffer selections that have REQUIRE-MATCH=t. I'm not sure I understand. What do you mean by "command history" and by "mini-buffer selections"? In my mind, the history stored in the hist variable is only ever exposed to the user via things like M-p, M-n, so there's not much difference between "that which is saved in the command history", and "that which is shown in the minibuffer" (tho dynamic filtering out of elements not in COLLECTION would change this state of affair). > To illustrate, imagine yourself, as a user, scrolling back through a > minbuffer history in order to see what your legitimate REQUIRE-MATCH=t > options are. Right now, scrolling back like that does not show you those legitimate choices, and after filtering out the !COLLECTION elements, it still wouldn't show you all the legitimate choices (only those you happen to have used in the (recorded) past), so if you want to see those legitimate choices, the user would be expected to use completion instead of history navigation. > When would you ever want duplicates to appear in your scrolling? And I don't understand why this desire (or not) to see duplicates in this scenario would be different from what it is in those cases where REQUIRE-MATCH is not t. > It would only delay your ability to see all your options. Agreed, which is why I'd expect the user to use completion instead. > The documentation does provide for HIST=nil, which -IS- a central > element of the bug report. It's unlikely this can be changed since it's been documented for ever and is used by a lot of code. Hence the need to use another special value (i.e. `t') to mean "no history". Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 15 12:40:15 2015 Received: (at 20063) by debbugs.gnu.org; 15 Mar 2015 16:40:15 +0000 Received: from localhost ([127.0.0.1]:47341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YXBaH-0003tQ-Is for submit@debbugs.gnu.org; Sun, 15 Mar 2015 12:40:15 -0400 Received: from mout.gmx.net ([212.227.17.20]:58275) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YXBaD-0003t0-VK for 20063@debbugs.gnu.org; Sun, 15 Mar 2015 12:40:11 -0400 Received: from [192.168.1.9] ([96.232.130.59]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M9fLX-1YhKaO2j6N-00D20W; Sun, 15 Mar 2015 17:40:07 +0100 Message-ID: <5505B5BF.2060505@gmx.com> Date: Sun, 15 Mar 2015 12:39:27 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: 20063@debbugs.gnu.org, "rgm@gnu.org >> Glenn Morris" Subject: Fwd: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <5500B0D6.8050604@gmx.com> In-Reply-To: <5500B0D6.8050604@gmx.com> OpenPGP: url=hkp://keys.gnupg.net X-Forwarded-Message-Id: <5500B0D6.8050604@gmx.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6T6AqDio1OU4XSrsBJhATKd4KFPMdpwRv" X-Provags-ID: V03:K0:G5pTK3TjSRrKSubjUfg6yWfkqRc8Rt7DkN4ZLc50x3bGRol7/dq TLfp5ymG2RNqgc0hX+BuOrPRNwNVw/meuiq6F9iSW+9O0NQBUZfr6lkF0DXiPYQKoeHsbyG uFiUK4VBiJognwyUrfrLPIpzYzmhaCd96eyySJQjQB2A2qotj3BeoiG6ABtUyX4KC1o0ouz WIpQF6HDT54R6F7VcFtdw== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 20063 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6T6AqDio1OU4XSrsBJhATKd4KFPMdpwRv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -------- Forwarded Message -------- Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Date: Wed, 11 Mar 2015 17:17:10 -0400 From: Boruch Baum To: Stefan Monnier On 03/11/2015 03:19 PM, Stefan Monnier wrote: >>> If the benefit is limited, it means the problem you mention is >>> correspondingly minor. >> I was referring to the benefit of your idea to filter out !COLLECTION >> elements dynamically, not the bug that offers the user nonsense or >> unacceptable HIST elements in the mini-buffer. >=20 > One of the benefits of filtering out elements not in COLLECTION is to > avoid providing "offer[ing] the user nonsense or unacceptable HIST > elements in the mini-buffer". So if you think the benefit is limited, > it necessarily means that "the bug" is correspondingly minor. >=20 > FWIW, I do think it's indeed minor (which is why I haven't written this= > filtering yet, even though I've had it in my "wishlist" for quite a whi= le). We clearly have a communication problem here, as my attempts to explain my point have failed. >> - how could one REQUIRE-MATCH=3Dt against a COLLECTION of infinite siz= e? >=20 > Theoretical answer: let COLLECTION be the set of strings that represent= > a natural number. It's infinite, and it makes sense (for example in > read-number) to use REQUIRE-MATCH=3Dt with it. ??? > Practical answer: read a file name in order to delete it. > The corresponding COLLECTION is as good as infinite (especially if you > include remote hosts via Tramp), and you do want to use REQUIRE-MATCH=3D= t > since you don't need to let the user delete a non-existing file. Good example. Understood. >> A user may normally want to retain duplicates in her general command >> history as a record of past activity, but not have those duplicates >> appear in mini-buffer selections that have REQUIRE-MATCH=3Dt. >=20 > I'm not sure I understand. What do you mean by "command history" and b= y > "mini-buffer selections"? In my mind, the history stored in the hist > variable is only ever exposed to the user via things like M-p, M-n, so > there's not much difference between "that which is saved in the command= > history", and "that which is shown in the minibuffer" (tho dynamic > filtering out of elements not in COLLECTION would change this state of > affair). You had suggested that a user who did not want to see duplicates in mini-buffer scrolling within commands such as `toggle-option' or `highlight-regexp' should set variable history-delete-duplicates to t. The command history acts as a log of commands, so there is benefit there is maintaining duplicate entries for the purpose of reviewing one's past activity. (eg. M-x , or M-: command-history). This is quite different than the desirability of having those duplicates display as options within a command such as `toggle-option' or `highlight-regexp'. -ALSO-, the command-history isn't the only history list (with potential duplicates) that could be used. You referred above to file-name-history, and there are many others (eg. face-name-history, or apropos-variable =2E*-history$ / .*-ring$ ). >=20 >> To illustrate, imagine yourself, as a user, scrolling back through a >> minbuffer history in order to see what your legitimate REQUIRE-MATCH=3D= t >> options are. >=20 > Right now, scrolling back like that does not show you those legitimate > choices, and after filtering out the !COLLECTION elements, it still > wouldn't show you all the legitimate choices (only those you happen to > have used in the (recorded) past), so if you want to see those > legitimate choices, the user would be expected to use completion instea= d > of history navigation. Currently, scrolling forward shows elements of COLLECTION, and scrolling backwards shows elements of HIST, so there's no need to resort to completion, just scroll forward. You are correct, though, that the desirable functionality is for scrolling, in either direction, offer all possible choices. That is exactly the point. >=20 >> When would you ever want duplicates to appear in your scrolling? >=20 > And I don't understand why this desire (or not) to see duplicates in > this scenario would be different from what it is in those cases where > REQUIRE-MATCH is not t. Correct. I don't think I ever claimed so. This seems to be another example of our communication difficulty. >=20 >> It would only delay your ability to see all your options. >=20 > Agreed, which is why I'd expect the user to use completion instead. I just tried this for both functions `highlight-regexp' and `toggle-options'. In the first case, the result was highly undesirable in that it took a long time to construct the completion buffer, and that it was incorrectly populated with 606 face options, when COLLECTION (the variable hi-lock-face-defaults) contains only six entries. In the second case, the completion buffer was constructed quickly and correctly with the contents of variable `toggle-option-list'. >> The documentation does provide for HIST=3Dnil, which -IS- a central >> element of the bug report. >=20 > It's unlikely this can be changed since it's been documented for ever > and is used by a lot of code. Hence the need to use another special > value (i.e. `t') to mean "no history". That's not what I'm reading in the documentation. What I see in the current documentation is only a discussion of HIST=3D!nil. In any case, a= n alternative option would be another value of your choice, besides t. Regards, Boruch. --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --6T6AqDio1OU4XSrsBJhATKd4KFPMdpwRv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVBbW/AAoJEDvrUfDmCx9LxEQP/2B9UJ0bQWedKgTRqo7w+D/I QWw3EygrjhOuFNouIRWndRTkVkHCVO5MrHpJvagLhr2n4nA793LA4HEsWJC24W8p 5vZxOIqkNnTGlIMPi5y0NgGi+fIyLpQkZsccV3Ayl0QH8BOychvz7NfiHcmwq4qS IQbueO8apTDRztb6SZrCqtMEVGpF5QF4zBM5U5RVcroGnyZR+UBK5rIZ6Oncxmgg LuU9kQBoK0hzn/AUBq1DYLTNDHZDqGwf4BzG7rPr3/fcKVrMKRAwcUQcqxyFHRyz VuCGvMov0MxXuIdzZaIGGN6MZJQj1C6+qVT47ZApKq+eW3qB0CZutwan07z+nNkL LKxd1trDC0/YrHAvvQW3HKu+nrUbCGmgufagwHtcrq+KUQa5KbCX7OUsnaTwoc90 8LWOETCleg2eFs1zkXRHkWSqAfK7PPjnYBl+cdazskPEUkfH9RbPqdCIEbpqDIQ3 7OFzcicuxMhxf/MsPpmbwZvDmWkd9Y/0HX5GVtVpGn1+8o/xLEqMTjbf1fKmMQYb VovDfJLx91AhqfmHCHXWqstdrfvd1tp86iA6BSwf5hrcAgGDDYb8nXRdPI0Jo7vV XmN908DTPo1Kn9S48yuDV+hWj2z3nbvvfamI4PyqP2vwffDWY12mlMbgILLiOHIn HipX7FpphGPZs8TAYF52 =1c04 -----END PGP SIGNATURE----- --6T6AqDio1OU4XSrsBJhATKd4KFPMdpwRv-- From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 15 12:42:15 2015 Received: (at 20063) by debbugs.gnu.org; 15 Mar 2015 16:42:15 +0000 Received: from localhost ([127.0.0.1]:47347 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YXBcE-0003xj-Al for submit@debbugs.gnu.org; Sun, 15 Mar 2015 12:42:14 -0400 Received: from mout.gmx.net ([212.227.17.22]:49743) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YXBcB-0003xX-Ln for 20063@debbugs.gnu.org; Sun, 15 Mar 2015 12:42:12 -0400 Received: from [192.168.1.9] ([96.232.130.59]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MAhTr-1YiQws3Djf-00BphW; Sun, 15 Mar 2015 17:42:10 +0100 Message-ID: <5505B646.3030709@gmx.com> Date: Sun, 15 Mar 2015 12:41:42 -0400 From: Boruch Baum User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 Subject: Fwd: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <5501AA22.5000503@gmx.com> In-Reply-To: <5501AA22.5000503@gmx.com> OpenPGP: url=hkp://keys.gnupg.net X-Forwarded-Message-Id: <5501AA22.5000503@gmx.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PrJ9T7AHWKppoA3LKurVuerbAu4lskkBP" X-Provags-ID: V03:K0:7kOPjH39TY0wDk2WWwQwJ8QsFo/s+di1T1C41ZzFABrI8TwU6jl IkoN/9oMXg/I8t0J1w7ul9+CnkgipFeMpwJDfCaDf+F5wV5xviv/jf/5OnQgWQ2Psvp9xYr NSz5ua/ZKTjnJWSwahklUTL5aL1KfC9/ToVlGVWgFV436zYnCcsBUAlEcb83qZvg6i8U/uQ G0n5ptn2KssTdiAyatzCQ== X-UI-Out-Filterresults: notjunk:1; X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: -------- Forwarded Message -------- Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Date: Thu, 12 Mar 2015 11:00:50 -0400 From: Boruch Baum To: Stefan Monnier [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (boruch_baum[at]gmx.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.22 listed in list.dnswl.org] X-Debbugs-Envelope-To: 20063 Cc: Glenn Morris , 20063@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: -------- Forwarded Message -------- Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Date: Thu, 12 Mar 2015 11:00:50 -0400 From: Boruch Baum To: Stefan Monnier [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (boruch_baum[at]gmx.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.22 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PrJ9T7AHWKppoA3LKurVuerbAu4lskkBP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -------- Forwarded Message -------- Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter Date: Thu, 12 Mar 2015 11:00:50 -0400 From: Boruch Baum To: Stefan Monnier On 03/12/2015 10:46 AM, Stefan Monnier wrote: > What problem do you see with using t to mean "no history"? To me, its counter-intuitive that HIST=3Dt means "no history", but that's= an implementation issue and, as such, is a decision for you to make based upon your informed judgment, and not part of my bug report. --=20 hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 --PrJ9T7AHWKppoA3LKurVuerbAu4lskkBP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVBbZGAAoJEDvrUfDmCx9L/5IQAIsg1N6qCIpZe/TYOyoNoXHo 8m84+zLzeEgcXfdbxB/GdwzEhrnJZy+/T87p4yAaR0wS8bmlsP7chc3C9+kiD6ib YhuT3nwst/aFjFLjuivrYkf+6h/jEtX27QgqkXL449YAmIkrucbWh0c5iFtXDWAW yCm2VVMNQcKobArqay0dUQgZCxS/Z4U91Xn9xM970dtofJznsKJTx07733Ueddab dh0bC1j0lRceRTrIWY8po0m7kLlQgLwWd46DnDc7Zp56RwB7wasszel5+PhyDGDZ rl6ZgKX+pdv/d08ja/CUyQ5ETjbKZ42oYijN3Dfb7LbPgCsA8qsCQt5e6UXCkjyg MS/XIztiaINQ+oeuJRUa+uBmrTbsOJoDaip6UWf3ZGjcYHjkBQcLaIHpDJ8QIX3+ m0Tv/vqCI1fMOiSkN/QZ28bHzYqtGR83BXHzyQNSgFcgdjC+h+Wy4hE5+YO+s3Nc 5uOr7vOGIr44tk8aTQQqinkxTkR/QWWM/CWE7HCt+LTu0N80Y5pZHH173Oef4MUS F5kQrw9FS6oREstlhGA3YKa9UIaUaBWDZEBBQ2rpBM8L2dBXyOg0T9jVCrRBsFlb Tt7jOf84iAGau2L075uvwzaShf9PnKKOV/aiyz0B+awBqhhrtcQ4R8NRbRE2a3k4 ysx65sjZ9ZG3N8WdkC0q =dIi2 -----END PGP SIGNATURE----- --PrJ9T7AHWKppoA3LKurVuerbAu4lskkBP-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 13 04:13:31 2022 Received: (at 20063) by debbugs.gnu.org; 13 Feb 2022 09:13:31 +0000 Received: from localhost ([127.0.0.1]:36292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAwl-0002aq-J9 for submit@debbugs.gnu.org; Sun, 13 Feb 2022 04:13:31 -0500 Received: from quimby.gnus.org ([95.216.78.240]:51166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAwj-0002ab-HS for 20063@debbugs.gnu.org; Sun, 13 Feb 2022 04:13:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4yR7lpWoC/x6uiLHvvRwm2cX/eW0mKCLsSlEZcIZrLg=; b=aAS8HZKlUjXdp9d62ZL4ON7+SW wT8HoW5AGgbU0xT83ZxMjdpMvFtkv/qQ3p33NdjIM1Z2GGSTvkhgwpptwCEzmEbhnKdXz603pNtvD 3SY+cQV+Xwat1fHdKOmLwQw20vZeU6XZQX7+FzkZchVZ5aMbM49BC9lkR1D8pJedFoHs=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJAwa-00015r-8Y; Sun, 13 Feb 2022 10:13:22 +0100 From: Lars Ingebrigtsen To: Glenn Morris Subject: Re: bug#20063: 24.4: read-from-minibuffer improperly setting hist parameter References: <54FCCC63.5080202@gmx.com> X-Now-Playing: Nils Petter =?utf-8?Q?Molv=C3=A6r's?= _Solid Ether_: "Ligotage" Date: Sun, 13 Feb 2022 10:13:19 +0100 In-Reply-To: (Glenn Morris's message of "Sun, 08 Mar 2015 21:08:57 -0400") Message-ID: <87iltjxh74.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Glenn Morris writes: > Nil means use the default history list. Eg see "Minibuffer History" in > the elisp manual: > > If you don't specify HISTORY, then the default history list > `minibuffer-history' is used. > > I don't [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 20063 Cc: 20063@debbugs.gnu.org, Boruch Baum X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Glenn Morris writes: > Nil means use the default history list. Eg see "Minibuffer History" in > the elisp manual: > > If you don't specify HISTORY, then the default history list > `minibuffer-history' is used. > > I don't see a bug here, other than perhaps the doc of completing-read > could stand to be more explicit, like the elisp manual is. I've now added this to the doc string in Emacs 29. I see that the t meaning of HIST has already been added to the doc string, so I don't think there's anything further to do here, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 13 04:13:36 2022 Received: (at control) by debbugs.gnu.org; 13 Feb 2022 09:13:36 +0000 Received: from localhost ([127.0.0.1]:36295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAwp-0002b9-Q7 for submit@debbugs.gnu.org; Sun, 13 Feb 2022 04:13:36 -0500 Received: from quimby.gnus.org ([95.216.78.240]:51182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nJAwo-0002ag-0U for control@debbugs.gnu.org; Sun, 13 Feb 2022 04:13:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zQ1Xpprl42juc7K4MusLkjAOIxRvQE0fQ3AfAksxNDE=; b=NlQQkoM6ofJHMa8c+PjNz3erxe MlatzhbBpmKGcu2Tv735amvKNOb/rwIeHPv5gRy7HlA0rVrKE/+kPLPFXUVaZ1blJgYCGuejZf81X Wz2af89TvQQOAIGYGmV/zHsiIis2JWg0B2DkxKihIKcmfv5VKpNuwaCW5QeK5sNc0Jqc=; Received: from [84.212.220.105] (helo=giant) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nJAwf-000160-Nq for control@debbugs.gnu.org; Sun, 13 Feb 2022 10:13:28 +0100 Date: Sun, 13 Feb 2022 10:13:25 +0100 Message-Id: <87h793xh6y.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #20063 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 20063 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 20063 29.1 quit From unknown Sat Aug 16 18:16:42 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 13 Mar 2022 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator