Re: Updating *Completions* as you type

[sbaugh@catern.com]

[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]

sbaugh@catern.com writes:
>>> That being said, yes this may be nice.  But minibuffer-completion-help
>>> already does sort the completions using display-sort-function, just like
>>> completion-all-sorted-completions, so what's causing the difference in
>>> behavior?
>>
>> It seems this is implementable in minibuffer-completion-help
>> by copying this code from completion-all-sorted-completions:
>>
>>               (setq all (minibuffer--sort-by-position
>>                          (minibuffer--sort-preprocess-history
>>                           (substring string 0 base-size))
>>                          all))
>
>Oh, very interesting!  Maybe completions-sort should accept a new symbol
>'history to behave this way?
>
>I already think this would be very nice for project-switch-project, for
>example, since I'm often switching between a few related projects.
>
>Perhaps 'history should break ties by alphabetizing, otherwise
>e.g. filenames you haven't visited before would be unsorted randomly.
>
>Hmm, actually the case of filenames is a bit complex.  Because for
>filenames, the strings we're completing over don't appear verbatim in
>the history.  So perhaps read-file-name would need its own specialized
>sorting function, which whenever you're completing in some directory,
>sorts to the front any files in that directory whose full path appears
>in file-name-history.
>
>>> Honestly the main place I find myself wanting different sorting of
>>> completions is for buffer completion - I'd prefer buffers to be sorted
>>> by most-recently-used.  Maybe we can just add such an option?
>>
>> Such an option would be nice.  Maybe the right way to support it
>> is to add a new sort function with the code above.  Then the caller
>> could provide such a function in the completion metadata.
>
>Oh, that's also interesting.  So there would be a function that the
>completion metadata could specify as display-sort-function, which would
>have the behavior of sorting based on history?
>
>That also makes a lot of sense, and would allow commands like
>project-switch-project and read-buffer to opt in on a command-by-command
>basis, which might be more sensible.
>
>So maybe adding 'history as a new option for completions-sort isn't a
>good idea.  Instead we should just add user options for enabling history
>sorting for files and buffers.  (And perhaps we could just enable
>history sorting by default for project-switch-project.)
>
>Also: it might be nice to switch between history-sorting and
>alphabetized-sorting during the course of completion, both for files and
>buffers.  Maybe we could do that by making a command which puts
>completion into a mode where it just ignores the display-sort-function
>specified by the completion metadata, and just always uses
>completions-sort.

On reflection, I think adding a new option for completions-sort is
indeed what we should do.  Otherwise, we won't get historical sorting
for non-programmed completing-read, which is a pretty common kind of
completing-read.  Here's a patch to do that.

We can always add display-sort-functions later for buffers and files, if
that ends up being desirable.

Also, tangentially, I think probably we should rework
minibuffer-complete-history and minibuffer-complete-defaults to be
persistent - as in, regular TAB afterwards continues to complete history
or defaults.  And there should be some way to reset back to normal.
That would be a good complement to this completions-sort change, by
maybe giving a way to switch on-demand to alphabetical sorting.  (I've
long thought this would be good and useful, but in particular it's
relevant for completions-auto-update since that will otherwise nearly
immediately reset the displayed completions back to normal.)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-historical-option-to-completions-sort.patch --]
[-- Type: text/x-patch, Size: 3851 bytes --]

From b97e311ee42f7f9021b3c0e017636e258dd6d5d9 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Tue, 17 Oct 2023 09:09:55 -0400
Subject: [PATCH] Add a historical option to completions-sort

This causes completion to sort based on history.  This is useful for
getting, e.g., most-recently-used order from C-x b.

We only do historical sorting when there's a completion-specific
history variable.  Otherwise, candidate would be spuriously brought to
the front if they just happened to match a string that the user has
entered before.

Also, the presence of a completion-specific history variable is a
decent proxy for "does history matter for this command?"; if there
isn't a specific history variable, sorting based on history would
probably be undesirable.  (Note also that the user can always choose
to do historical sorting mid-completion by running
minibuffer-complete-history.)

* lisp/minibuffer.el (completions-sort): Document 'historical option.
(minibuffer-completion-help): Support 'historical option.
---
 lisp/minibuffer.el | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index f53cd739e2f..782efff80f9 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1313,14 +1313,26 @@ completion-cycle-threshold
 (defcustom completions-sort 'alphabetical
   "Sort candidates in the *Completions* buffer.
 
-The value can be nil to disable sorting, `alphabetical' for
-alphabetical sorting or a custom sorting function.  The sorting
-function takes and returns a list of completion candidate
-strings."
+Candidate completions in the *Completions* are sorted depending
+on the value.
+
+If nil, sorting is disabled.
+If `alphabetical', candidates are sorted alphabetically.
+If `historical', candidates are first sorted alphabetically, then
+candidates occurring in `minibuffer-history-variable' are moved
+to the front based on the order they occur in the history.
+If a function, the function is called to sort the candidates.
+The sorting function takes and returns a list of completion
+candidate strings.
+
+If the completion-specific metadata provides a
+`display-sort-function', that is used instead and this value is
+ignored."
   :type '(choice (const :tag "No sorting" nil)
                  (const :tag "Alphabetical sorting" alphabetical)
+                 (const :tag "Historical sorting" historical)
                  (function :tag "Custom function"))
-  :version "29.1")
+  :version "30.1")
 
 (defcustom completions-group nil
   "Enable grouping of completion candidates in the *Completions* buffer.
@@ -2510,6 +2522,15 @@ minibuffer-completion-help
                                           (pcase completions-sort
                                             ('nil completions)
                                             ('alphabetical (sort completions #'string-lessp))
+                                            ('historical
+                                             (let ((alphabetized (sort completions #'string-lessp)))
+                                               ;; Only use history when it's specific to these completions.
+                                               (if (eq minibuffer-history-variable 'minibuffer-history)
+                                                   alphabetized
+                                                 (minibuffer--sort-by-position
+                                                  (minibuffer--sort-preprocess-history
+                                                   (substring string 0 base-size))
+                                                  alphabetized))))
                                             (_ (funcall completions-sort completions)))))
 
                       ;; After sorting, group the candidates using the
-- 
2.41.0