unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	"64656@debbugs.gnu.org" <64656@debbugs.gnu.org>
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	[thread overview]
Message-ID: <86jzrhlrub.fsf_-_@mail.linkov.net> (raw)
In-Reply-To: <SJ0PR10MB54881F12042B9FA2224AF962F339A@SJ0PR10MB5488.namprd10.prod.outlook.com> (Drew Adams's message of "Wed, 19 Jul 2023 17:23:36 +0000")

>> > 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.





  reply	other threads:[~2023-10-20  6:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-15 23:35 bug#64656: 29.0.91; Doc of minibuffer histories and completing-read - automatic addition of completions to DEFAULT list Drew Adams
2023-07-16  5:24 ` Eli Zaretskii
2023-07-16 14:34   ` Drew Adams
2023-07-16 14:58     ` Eli Zaretskii
2023-07-18 20:27       ` Drew Adams
2023-07-19  6:35         ` Juri Linkov
2023-07-19 17:23           ` Drew Adams
2023-10-20  6:47             ` Juri Linkov [this message]
2023-10-20 16:48               ` Drew Adams
2023-10-29 18:29                 ` Juri Linkov
2023-10-29 22:15                   ` Drew Adams
2023-10-30  7:44                     ` Juri Linkov
2023-11-13 18:14                       ` Drew Adams
2023-11-14  5:57                         ` Thierry Volpiatto
2023-11-14  7:28                         ` Juri Linkov
2023-11-05 18:11               ` Juri Linkov
2023-11-06  7:28                 ` Juri Linkov
2023-11-09 16:34                   ` Juri Linkov
2023-11-09 16:48                     ` Eli Zaretskii
2023-11-09 17:03                       ` Juri Linkov
2023-11-09 19:31                         ` Eli Zaretskii
2023-11-10  7:45                           ` Juri Linkov
2023-11-10  8:15                             ` Eli Zaretskii
2023-11-12  8:13                               ` Juri Linkov
2023-11-13 17:17                                 ` Juri Linkov
2023-11-13 18:14                                   ` Drew Adams
2023-11-14  7:30                                     ` Juri Linkov
2023-11-15 17:52                                       ` Juri Linkov
2023-11-10 19:51                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-07-20  6:19         ` Eli Zaretskii
2023-07-20 16:45           ` Drew Adams
2023-07-22  8:07             ` Eli Zaretskii
2023-07-16 13:40 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86jzrhlrub.fsf_-_@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=64656@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).