From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list Date: Fri, 20 Oct 2023 09:47:12 +0300 Organization: LINKOV.NET Message-ID: <86jzrhlrub.fsf_-_@mail.linkov.net> References: <83y1jga0nr.fsf@gnu.org> <83o7kb9a40.fsf@gnu.org> <86bkg84de3.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11615"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: Eli Zaretskii , "64656@debbugs.gnu.org" <64656@debbugs.gnu.org> To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 20 08:56:50 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 1qtjRB-0002vq-AV for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 20 Oct 2023 08:56:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qtjQz-0006m7-SD; Fri, 20 Oct 2023 02:56:37 -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 1qtjQy-0006it-7g for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 02:56:36 -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 1qtjQx-00038J-VM for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 02:56:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qtjRO-0003gR-Up for bug-gnu-emacs@gnu.org; Fri, 20 Oct 2023 02:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Oct 2023 06:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64656 X-GNU-PR-Package: emacs Original-Received: via spool by 64656-submit@debbugs.gnu.org id=B64656.169778497414079 (code B ref 64656); Fri, 20 Oct 2023 06:57:02 +0000 Original-Received: (at 64656) by debbugs.gnu.org; 20 Oct 2023 06:56:14 +0000 Original-Received: from localhost ([127.0.0.1]:38508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtjQb-0003f0-LK for submit@debbugs.gnu.org; Fri, 20 Oct 2023 02:56:13 -0400 Original-Received: from relay1-d.mail.gandi.net ([2001:4b98:dc4:8::221]:51967) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qtjQT-0003eB-RI for 64656@debbugs.gnu.org; Fri, 20 Oct 2023 02:56:08 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 9356C240003; Fri, 20 Oct 2023 06:55:31 +0000 (UTC) In-Reply-To: (Drew Adams's message of "Wed, 19 Jul 2023 17:23:36 +0000") X-GND-Sasl: juri@linkov.net 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:272775 Archived-At: >> > Try this: >> > `C-h v org TAB' >> > `M-n' >> > `M-n' >> > ... >> >> Why candidates are inserted in a random order? >> It would make sense to insert them in the same >> order as they are sorted in the *Completions* buffer. > > That's one reasonable possibility. > It's not the only one. I tried to use 'completions-sort' to sort 'C-h v M-n' default values. By default, it sorts alphabetically that makes sense for 'C-h v M-n'. But this broke many other completions. For example, currently 'C-x b M-n M-n ...' provides the default values sorted by the order of recently used buffers that is very useful. It keeps the order of 'buffer-alist' in 'internal-complete-buffer'. Another example is 'C-x p p M-n M-n ...' that currently uses the order of recently accessed projects from 'project--list'. This means that we can't change this default behavior. So currently there are three different sorting orders used by default: 1. 'TAB' uses the alphabetical order; 1. 'M-p' uses the historical order; 2. 'M-n' is unsorted and follows the order of the caller. > The fact is that the candidates are in > a useless order, particularly when the > completion table is just obarray or an > unsorted, filtered subset of obarray. This means that the caller should take care about sorting completions is a meaningful order. But then a new metadata type similar to 'display-sort-function' should be added such as 'minibuffer-default-sort-function' that might be a hassle. So maybe this could be improved with a simper fix? This is why I added such condition below: (eq minibuffer-completion-table 'help--symbol-completion-table) Please try this modified function, it should work with 'C-h v M-n': #+begin_src emacs-lisp (defun minibuffer-default-add-completions () "Return a list of all completions without the default value. This function is used to add all elements of the completion table to the end of the list of defaults just after the default value." (let ((def minibuffer-default) (all (all-completions "" minibuffer-completion-table minibuffer-completion-predicate))) (when (eq minibuffer-completion-table 'help--symbol-completion-table) (setq all (pcase completions-sort ('nil all) ('alphabetical (sort all #'string-lessp)) (_ (funcall completions-sort all))))) (if (listp def) (append def all) (cons def (delete def all))))) #+end_src > Why are all candidates inserted into the > `M-n' queue at all? And why no ability > to filter them or sort them - during > completion (i.e., taking the current > completion state into account). Because 'M-n' is not completion.