From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.bugs Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Date: Mon, 21 Aug 2023 06:34:54 +0200 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=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34896"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , "heimeborgia@protonmail.com" , "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>, Juri Linkov To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 21 06:36:31 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 1qXweR-0008ka-HK for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Aug 2023 06:36:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXwe3-0007JL-Gc; Mon, 21 Aug 2023 00:36:03 -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 1qXwe0-0007F1-RC for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 00:36:01 -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 1qXwe0-0003SI-J0 for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 00:36:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qXwe2-0004p2-Hi for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 00:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Christopher Dimech Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 04:36: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.169259251318449 (code B ref 65348); Mon, 21 Aug 2023 04:36:02 +0000 Original-Received: (at 65348) by debbugs.gnu.org; 21 Aug 2023 04:35:13 +0000 Original-Received: from localhost ([127.0.0.1]:55167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXwdE-0004nU-Rp for submit@debbugs.gnu.org; Mon, 21 Aug 2023 00:35:13 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:45223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXwdB-0004nB-7I for 65348@debbugs.gnu.org; Mon, 21 Aug 2023 00:35:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1692592494; x=1693197294; i=dimech@gmx.com; bh=Eg5IPzjwZBFNgCgOdhge58LYu7GA+EgLc/CoTzhRMqk=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=S5WsbbmwqVy5u/fOE3Ltc7lN95icrmyt6QhGNUoLXCUAF+e3tVIWkHXf5pXpLc4T/rWaHL/ 6I/r/V+sxeXll4KRreh2gn/9i2snFdlV50Mus9RS/CKJboHrFeYzSldxFo3r30Q1CNgC9IMFW 5UM9QV9MxAwcZ8ZRuVuiesgIt7uGBVv8AKjHNHCgx488vQwXHy5IPtAcSzM62rOVoAOTSqxil pqRM73cX/WBZ9vqMrJSWRYRBX/k3MIEQjcVakyZ0c68arOLN0su65pfIaMW7elWnISBkJtlem 3Tf2oL3VPspg/bOxmYTF1tIaWNpyh/vS0CMloZM8tzDeQrFde7sA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [141.8.81.247] ([141.8.81.247]) by web-mail.gmx.net (3c-app-mailcom-bs13.server.lan [172.19.170.181]) (via HTTP); Mon, 21 Aug 2023 06:34:54 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:l4C4upFg1OBe5Nu/5znPcCysEyMj+yeqmg8a+ZC1468lGhc2KseElX3rUz54q2U6Fmh4/ bmnbgrD6k9qzIhfioqlmV9fmQ5R/mu8W0/komcSVR149isx5FgraW2UmOvxkvnrwNsgF5fh6XadG lteSd5v4FXHIuIjbzfQ0JVTDHfvMhgDJETCr53mwh2CGQAKtKt+9lvEvglnYDzWYeISaGETcePZB 3pUdEa5jSCPvD7SlsfMh8tENkYOMD+HctFaDglLcpcXW7daDpFwNp3JY2willn2YvlwaP+rhdaw9 38= UI-OutboundReport: notjunk:1;M01:P0:xItEM9YN2b4=;5RqzNC6k0iKv6qGg6JMvKIw2E6x 0FQ9Co6kff6EMHKBttmghubcjmngnFccbwd2rovh/0a6ibjcODM7UK077kEKTQnajFhjmapO1 sE2R5b8l5oRXwK8FoYMvfcZ6xSIkaGq4AAB8Zwwn399lXVUX2s6RrlGixQtPNsq3DtMbvG0aE k72hhw54ayPQT4IFQRSOJBox5DV6vksgn5CQyJw62kdoJtOXvCBMmRRSjYSLdDmLlUweFJKyY rcAxWa+vYdYw4SpvzCLjh5ejEd7ZPxmuElf4a8gZu/u4QI1nLUeDuZPH1OfjlPP9n2K2aLlJs xmeUt6pZ2EVkFLcQpGqAyeEEJlAxSQXmxRV5Csk0K2FAtOyDCpB/Dj+a+ljiqwdREwXhTph62 Sdm8JP++VHARV6EcWq1u+3d9H73biJjffhdiGjZjk32Zer9MCEM0RUGyIUdrvDszxDxg/ShPN H9zFZuCpqLu/fjSGeIc7zvJ06prYeZ9tZ2yDch6Pdj4V+f9ZtPsdpgQvjhecQThmV+bkl+Nfs 86f0sGMOFiBWwdsQTCRjVF0FGZPyOziJXJUV9Uh2buaPVsBxNz4/H0LlrxWzAnZ4rQBoEj99L WUNKjN+OQUkaiNx25LBSp/7nZWdXKDOxjDHwWtxlyJKbi/yhBT4L23e9fp9Glf7cydq67SBdh WkiD1KnN0NX9zrYmq2fpKM4kF1jWh8bLcri3O+UGcdNI7CkVxmj8ZBx6ObWPSwXeg14XDfzwO iHwJjqDi4q8b6ecZPYGrp3cSCXZdatt5lps3RP6uaxELPmcAO+risLvOAJIT+WOKminAEdJo 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:268055 Archived-At: > Sent: Monday, August 21, 2023 at 12:23 PM > From: "Drew Adams" > To: "Juri Linkov" > Cc: "Eli Zaretskii" , "heimeborgia@protonmail.com" , "65348@debbugs.gnu.org" <65348@debbugs.gnu.org> > Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry = twice consecutively > > > > 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. > > > > 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-Com= pletion.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). I would agree with such evaluation. One should enter COLLECTION and then instruct the function how to use it. > > 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 > > > > > >