From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Date: Mon, 21 Aug 2023 00:23:08 +0000 Message-ID: References: <7D2p2XmGzWwhYjrI_PaUsn8r_NaQf-B0eAf7AmeRIhBEl84z79j_jKky-Lqlt6nc52SQ7T5yrL9OdqUzou1Mh3zQzgJx-SV6kIvc9Km8bDg=@protonmail.com> <83a5un35h6.fsf@gnu.org> <83o7j2yh47.fsf@gnu.org> <86lee6owj0.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18131"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , "heimeborgia@protonmail.com" , "65348@debbugs.gnu.org" <65348@debbugs.gnu.org> To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 21 02:24:16 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qXsiN-0004YP-Hs for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Aug 2023 02:24:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXsi9-0000Oj-Ri; Sun, 20 Aug 2023 20:24:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXsi8-0000OY-Lt for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 20:24:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qXsi8-0007Bb-EJ for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 20:24:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qXsiA-0006dM-7o for bug-gnu-emacs@gnu.org; Sun, 20 Aug 2023 20:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 00:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65348 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 65348-submit@debbugs.gnu.org id=B65348.169257740425456 (code B ref 65348); Mon, 21 Aug 2023 00:24:02 +0000 Original-Received: (at 65348) by debbugs.gnu.org; 21 Aug 2023 00:23:24 +0000 Original-Received: from localhost ([127.0.0.1]:55065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXshU-0006cR-Cr for submit@debbugs.gnu.org; Sun, 20 Aug 2023 20:23:24 -0400 Original-Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:3648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXshO-0006cG-Sx for 65348@debbugs.gnu.org; Sun, 20 Aug 2023 20:23:19 -0400 Original-Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 37KNH9tH005050; Mon, 21 Aug 2023 00:23:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2023-03-30; bh=wLvkeyR9EVmJKj6mq1ZNY/Nr+5C0CuibQED2tqVOaDo=; b=OekkKhA21DUX0+/FSSxI02W7EH+TBShscGH/qQp+3kI7TYQKYthT2cPH1OBYnQmpZSbe vaao+EiQzl5TFQl5afim49EmGTrwMC10vRnkTZiQOTn6Zx8G8K+ewRhDvHfV0HssUolJ XCM5ItkkWyXbSAlm5rZNvD1tjo0+nru0fATdjW6F7sPH6uJ5LxQgC5DGvu13Yaw0AH77 E4r3jYitsh7eXBTwzRVqZ8VwTi4dR8rQFBSxxPb2kZ0baYI66Zc39oWDuEiUa30wxHaA X7masVUrarkrycEdwL+xmcwDT14qLCEqHQ6QUGnB8ALapRM6HgVcoCiZurEaYpCMw0zg PQ== Original-Received: from phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta02.appoci.oracle.com [147.154.114.232]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3sjnma1q9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2023 00:23:11 +0000 Original-Received: from pps.filterd (phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 37KNAqjr026716; Mon, 21 Aug 2023 00:23:10 GMT Original-Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2044.outbound.protection.outlook.com [104.47.66.44]) by phxpaimrmta02.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3sjm632t3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 21 Aug 2023 00:23:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XrNMDVDL0lSOzbQ1RTY8mP39zicUW64bwDCTv4MYIgm1wta/9aOzXs5Pmles1gFHA3QMfgB/igudPbr+Iq1/XGhNP1C9OjNgXxwxw7DENVy6su6IqJRlIHYa20VlggSEZd1QFuzPiuaP9jw3JqcCyMBin9QWcAr/Drx9y3fmpJFUQFQN/npRohDRkpi31PDXbJErwMnMvR7XiJfdqWFBdo4FeRIz3f57Dk1+uf622fCES5bGBfIuPflgC+ofkTAuaydIwgAPBwjnO3UmM+OwcxDQcKO+Ya/l0WOmTIa/s57OITj4kQkviZukP3pV7dW4KF3NNoTJSzv6/iNHk4jVrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wLvkeyR9EVmJKj6mq1ZNY/Nr+5C0CuibQED2tqVOaDo=; b=hKnadqFgOvJi75cArCzENhNqmUHay/5oW2JlW0Y5Nqpz3M9VQ8Tg+TIGO/pOHOYT2bn+tS2YrGhwGyxs67pxVBoG9cwZLmhucbgPKa1hOzaaT1fJfR17vz86OeEbS20AoVMHico0XrD31ZATNPWFzSYsgPj9PGySw7IazPYLSBTb2+zJgOX1hjeXeQ91lvsavtP4cVCmauPiFp0AqDZKsC46tlpwRvOyLK42Du/SXChhOPpdNZ6OzXL3fNLeoZCxLv7874ox0PxNE8SmKOFOlQcux2v55ouJ8U77eUSDtzTufCxzfCNgI+axUQJMh4309fYL3mWfgtdgvW2IGTGMxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wLvkeyR9EVmJKj6mq1ZNY/Nr+5C0CuibQED2tqVOaDo=; b=pSsfmFnkIZA/KAi3jQmG++7VjjdFrnv5jookPxKD6nKls4gzLCcQIViQjDkQVAv+paUvh//vNW4fllxdGT41QKtoCiFkfAzSZOwE6udW3XDJ9VybrWCyb8Q4qDuYNZRJWQuhPD0FVa1gY++Ac+UlomGyTohi2tkQoSGArxIqzYk= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by CO1PR10MB4657.namprd10.prod.outlook.com (2603:10b6:303:96::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.24; Mon, 21 Aug 2023 00:23:08 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::26ee:5721:d884:4321]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::26ee:5721:d884:4321%5]) with mapi id 15.20.6699.020; Mon, 21 Aug 2023 00:23:08 +0000 Thread-Topic: [External] : Re: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Thread-Index: AQHZ04TfKD7t82DCr0ihIwjIpmzs06/zyPzQ In-Reply-To: <86lee6owj0.fsf@mail.linkov.net> Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|CO1PR10MB4657:EE_ x-ms-office365-filtering-correlation-id: ab23260c-6096-44fc-22d3-08dba1dccb90 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PW0SJ2yd8fxRdLTGv5hyRoFXfuYUGuzK5p1fPINAtNz5BdFi9FVDqxA1aaSKkYfLRJ0sMbQVCKmwI/wRde+RhspnBrSX8vzETwkACPeSP4GEYxUpTv2M2Ef9Fn6wQIcLbOUqxqxs+iSVVWTiq20Of0PJmA/kfI1TaFWD4/LrfA0eRdLjnD/aEq84m858EzGFLMx87W5Y4LIUHFDLuzPhwuCAEKN3otL/QPKaPkZXR5CpRKNU5siCpy0UjNuR0OA+6zcs+IXMSA9qOmcmTFQPc8cOhrxU76s8d2BS7eI2DjtYvi65l0OSkwtfrnSkI9+vvK3LhoKJ4uUlXtwnoghqUzJqrHcYg2HKl7aHv34Gj4lTUsKHsTJbVFH0lFYSvBFb6aUCHu/aRz8A8MD00nBkrX8DHY1S5lEYeDKvhUV3RiF92QTW71GPpbQA5GEWBFaiClynZW+ddQnDR2XtYss7dxBY1Wynmao5TpRT0rqlMwD7d5EtXUDqINscdkImfgLxeXGQc/zFQblNIJd25/Gs82UvX2nEDKqsu3E+gTtMGb4wQXFecbb04ej6WysLronWuRYa30kNmgP3DSgwHR73C36gj8t0vuBMUIv0JUYf/YQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(396003)(136003)(376002)(346002)(366004)(39860400002)(186009)(1800799009)(451199024)(66446008)(66476007)(64756008)(6916009)(54906003)(76116006)(66556008)(66946007)(316002)(9686003)(66899024)(8676002)(8936002)(4326008)(41300700001)(122000001)(478600001)(966005)(71200400001)(55016003)(38070700005)(7696005)(38100700002)(6506007)(2906002)(83380400001)(86362001)(44832011)(5660300002)(33656002)(26005)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: DI6QRo9Lf0KSO0p2koXeZ7ix6rWsAkcTD7TQQMUrWQiSVN2S+PKC0wd2+pzpLEnPKRLgud9FBtFV7aqqGiFEjSika/ft6kEW2fm9PlLvk9MAA7IXpA4qUATicaVLsynLweFShfbcbG5WVU6bwo+I3JJQI2znBQRqRXmbZW2GwZqutPKkNvQs3GCK44Q/Pfm9NX6ECmWCVWXHIl6QyxnuTYld5NrDcDWvDUvkTuieAPaP+c4ZnzBakCP6k3zJRMU5woORMhOS9HnMHIHE2EL7OUD5bltlNPyOZGHJGda6KWti8IUnvAjUiLb5+lvxs6NAx88OpL6hueRNt6/tVR31Zzbju5I2R6oEkdCiv1BFTUKdX1qeFNL5ksGsBeFbbSqcWfm5yBHCIPfJnFWXS+HNgiMvxH3pcpm06yG+pEmRWVXtvH8bzXMCqXSin4Dgatd16jOoS6oDyjFxaL+XgMc3iCN1QOrPjqDMxO1fuc4FGUH0eARB2tYmYyzEDW4otXyWAolp8h/0iVQZ0MBXTr3T53myEbA8Qc++JOaHIHuALKt1y7qdHc1Z4yjw4vLin0N/HbIG0efc6omtEEabubqx/0uo6t1kwHmNy0i1zZrMtMA2zwSWx92SVu0E3qrnfOsEQFOnVWtbiqe4YzS4asUlXxlgvyKcABuwuTaFcjAw/zxoBk5utCeIiyaWSGwCKwJan5bvFN1OUdMMtTi3ZW2M6v9NCmW71fhoV2U7lVv7ELUqeHkYlcc6439J0P 5K8vjy0S3gdkMQh6NAWTy3/Zx4ugw8hUrvDcKCmOPZlmYVU9TN7Z95hj31xXv4eE2W+8+3uhcAlIebHaD/FzIMf8YtO+ElLMoG X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: YZaIm/TtBG30VXUynXQGMlv+QTbTQAMw2GgH7ylN1S7Gu4FgZCoXOHlBQ2b/hmtt9jeXNXICp7MdObLRcQ+ILszSn7lhvCYxlvQBb8CXjBO5nzKPgR9CW41PtwX0Xn87jqkJqNOsvTsiP2HrAZCGvLXsZ8hNdFB2zH1qgx5oa9yd9O3PqneSfYCueZ4RKyho5To3tXjyCCL+E1IyHW/Wp1vYsNi4rgyEOwuEUiRjatmx+gTNZYkksd/NEeYkcb3HW2L6zZlFRxctvbGgW16EawIxPQqEmbwyOQBfhSQ26krucJHJUkWxxWMYbTelNpR1sUjLaDQNH7Hmv0aSd72gkTEwvjnTxTYA7Z9yQVn9Tqlv/EWYKe++/ej4HcLaHrmkHkcvo69yxyNlxlhwyo63Mc5iace5V2BdzmZdmwd8YY8TmoIboRU+nmNCsddP8LdImjBm63G0ZYLnYWsATAXHbbNWBJQZI3H5NtwBdBfW71tXCaxS+LfIMrMCi4BBSz+tQqRKiYQhtpfryEIl+mjzvkcvdaTz6VUCYUiNy+j38AHyXWudTK5CAVEAh7+uDDZQpT5p1GMwhJqIVbbAMBoINcuEtB7De8UfBuJvo+w4GvFw/QoLFKasMwPpc79cwmjRF5ZlnEOlss8Iaq5yF8q5TlotY37s0E0p6nmRLbr6518UoTIEslHNIDO2IEKK4jWk0ccqq1/Op0wnqhNIXzh8k4wX8p+fuvs51eeigIFBQlJCsw pvnY3khINlxjGXI7B6QGGF6aefAah7czc2u+R0pa3UVzGalrcm4TEuNIamfzeqlWkaoCaegeGkKiJ5VguM922zcazQst6+Dh/c X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab23260c-6096-44fc-22d3-08dba1dccb90 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2023 00:23:08.2921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pgNbssyWGq61fIWUS7FJIK3uEBKbDHTKm35/LDUqpL5IZsJKhV/R2LVWXhYrvr5QKnT1gSIihUGTyCbxrNEc8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4657 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-08-20_15,2023-08-18_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 mlxlogscore=916 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2306200000 definitions=main-2308210001 X-Proofpoint-ORIG-GUID: JmX06AdINfph5AYIo0FiuZrmTdLfao7l X-Proofpoint-GUID: JmX06AdINfph5AYIo0FiuZrmTdLfao7l X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268045 Archived-At: > > In case you're thinking, for your "obvious" use > > cases, of a case where you have few completion > > candidates, such as just "alpha", "beta", "gamma", > > then let's not forget that you can already cycle > > among those now, as completion candidates, without > > having them added to the future history. That's > > available since Stefan added candidate cycling, > > AFAIK. >=20 > Your answers are too short. Please elaborate > what do you mean by "candidate cycling" and > what keys do you press to cycle candidates? Sorry. First, I'm no expert on the cycling provided by vanilla Emacs. I believe Stefan introduced it. He can probably tell you more, and better. There are two different completion metadata entries, `display-sort-function' and `cycle-sort-function'. See (elisp) `Programmed Completion': https://www.gnu.org/software/emacs/manual/html_node/elisp/Programmed-Comple= tion.html (I don't see why anyone would ever want those two to have different values, but I don't think my ignorance about that is very relevant here.) Dunno whether there is some key that, by _default_, invokes one or the other of those functions. I use them in a two of my libraries, `sortie.el' and `keysee.el', to use vanilla Emacs cycling for cycling and display, together. With sortie.el, when you hit a key (`C-,' by default) the candidates in *Completions* are re-sorted, and so are the candidates you cycle through (same sort order). So when you cycle to a candidate, that's also the current candidate in *Completions*. To turn on cycling you need to give `completion-cycle-threshold' a non-nil value. Then you can cycle among candidates using `TAB'. keysee.el uses key descriptions as candidates. sortie.el uses sort orders (functions) as candidates. keysee.el uses sortie.el to let you change how its candidate key descriptions are sorted. In the Commentary of sortie there's a simple example of using the features it provides. Here's most of that example: (defun my-completion-with-sort-cycling () "Read and echo choice using completion with sort-order cycling." (interactive) (minibuffer-with-setup-hook #'sorti-bind-cycle-key (let ((sorti-current-order 'order1) (sorti-sort-function-chooser 'my-sort-fn-chooser) (sorti-sort-orders-alist '((order1 . "alphabetical") (order2 . "by length"))) (sorti-sort-orders-ring (let ((rng (make-ring 4))) (ring-insert rng 'order1) (ring-insert rng 'order2) rng))) (message "RESULT: %S" (completing-read "fff: " (my-collection-fn '("aa" "bb" "ab" "aaff" "c"))))))) (defun my-collection-fn (candidates) "Collection function that provides metadata for sorting. Sorting is per the current value of `my-sort-fn-chooser'." (lambda (string pred action) (if (eq action 'metadata) (let ((order (my-sort-fn-chooser))) `(metadata ,@(and order `((display-sort-function . ,order) (cycle-sort-function . ,order))))) (complete-with-action action candidates string pred)))) (defun my-sort-fn-chooser () "Return sort function for current value of `sorti-current-order'." (if (eq 'order2 sorti-current-order) 'my-sort-by-length 'my-sort-alphabetically)) So for example, with both sortie.el and keysee.el loaded, if you turn on mode `kc-mode' then * `S-TAB' shows currently available key bindings. * `C-,' re-sorts them in a few different ways (for both *Completions* display and cycling). You cycle among the available sort orders, to choose one, with `completing-read'. * `TAB' cycles among the key bindings, to choose one, with `completing-read'. ___ As I say, I don't know how others make use of the vanilla cycling feature. Maybe Emacs provides a key for such cycling by default, but I doubt it. I think you have to define the cycling yourself, by defining a function (such as `my-collection-fn' above) that dynamically sorts the candidates to produce a COLLECTION that's sorted as desired. But is it really needed - by default, i.e., in general - to be able to cycle among all candidates in COLLECTION? Certainly some libraries, such as Icicles, offer that, but it's not as if it's so essential that vanilla Emacs should provide it by default, I think. It makes sense to give coders ways to provide candidate cycling when they want it for `completing-read'. My main point was that IF any such cycling of COLLECTION entries is provided, it need not, and should NOT, be part of the history (future or not). Leave the history cycling to minibuffer input HISTORY and to DEFAULTS. If you want cycling of all candidates in COLLECTION then provide that as a different kind of cycling (different key). > Then maybe this cycling could be used instead of 'M-n'. No, not in my opinion; not at all. `M-n' should be only for cycling forward in the history, just as `M-p' should be for cycling backward. Users should know that that's what's being cycled, and that those things are NOT, in general, candidates from COLLECTION. (Think lax completion.) The "feature" of unequivocally adding COLLECTION to the history mixes things that don't belong together. It doesn't help users, IMO; and it can confuse them, by mixing carrots with car parts. My call is to first-and-foremost give control to (1) users interactively and (2) coders who call `completing-read'. We already have a way for any coder to add all of COLLECTION to the "future history": use it as, or include it in, the value of argument DEFAULTS. _End of story._ That gives coders 100% control over such addition. It's not blindly imposed on them. And it's easy to obtain when/if they want it. Easy peasy. They already have COLLECTION - just pass it also as arg DEFAULTS (or part of DEFAULTS). Arg DEFAULTS should, _alone_, determine/define the "future history". You can do anything you want with it, including get the current behavior that gets imposed unilaterally. But you need not live with that imposition. Do I want to argue this in emacs-devel? Not really. I really don't have time for such things these days. But do I wish something were done to remove this imposition and give control back to coders & users? Absolutely. If this makes sense to you, go for it. And I think it's simple to do: (1) Stop filling future history with COLLECTION, or at least provide a simple means to stop that. (2) Point out to users that IF they want to for some reason (the "many" use cases Eli hinted at), they can simply include all of COLLECTION as, or in, the future history, by just passing it as (or as part of) the list arg DEFAULTS. What's more, they can sort it first, any way they like. And they can filter it, if they don't want to include _all_ of COLLECTION. The current "feature" is brutal - it's a one-size-fits-none, IMO. It was never needed (DEFAULT suffices), and it can't be turned off. #2 is maybe not obvious, even though it has been available since Day One. If it were really so useful in "many" situations then I think we would have seen "many" users pass COLLECTION also as DEFAULTS (e.g. before Emacs 23). I seriously doubt we'v seen many - maybe not even any. Yet someone thought it was a great idea to impose that behavior always, on everyone - every call to `completing-read' that uses an explicit COLLECTION. Dunno who did that, and as Eli says, apparently it was done in Emacs 23. I guess many of us just never noticed it. BTW, what about a COLLECTION that's not explicit, that's realized bit by bit with a function? That doesn't work anyway for this "feature", I guess. You need to manifest an explicit COLLECTION, in order to add it to any history (history needs to be manifest for the call to `completing-read'). (I guess if you know the candidate domain you can use `all-completions' with a function COLLECTION to get an explicit version, if you really need to add it to the future history.) HTH. And BTW, thanks, Juri, for enhancing DEFAULT to be able to be a list (long ago). ___ https://www.emacswiki.org/emacs/download/sortie.el https://www.emacswiki.org/emacs/download/keysee.el