From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: sbaugh@catern.com
Newsgroups: gmane.emacs.devel
Subject: Re: Updating *Completions* as you type
Date: Sun, 26 Nov 2023 13:33:45 +0000 (UTC)
Message-ID: <87v89ohc6f.fsf@catern.com>
References: <87bkd3z9bi.fsf@catern.com> <86zg0fu99i.fsf@mail.linkov.net>
 <875y33v73h.fsf@catern.com> <87y1fztke8.fsf@catern.com>
 <86r0lrw17x.fsf@mail.linkov.net> <87il5xlf9b.fsf@catern.com>
 <86y1esuajx.fsf@mail.linkov.net> <ierleas4fcr.fsf@janestreet.com>
 <86v89ws5t3.fsf@mail.linkov.net> <iercyw445tu.fsf@janestreet.com>
 <86v89vzf1o.fsf@mail.linkov.net> <87pm03jn3w.fsf@catern.com>
 <861qcjw3ch.fsf@mail.linkov.net> <ier1qcin8db.fsf@janestreet.com>
 <86r0ki2on3.fsf@mail.linkov.net> <ierttpdlqe4.fsf@janestreet.com>
 <86leao519y.fsf@mail.linkov.net> <87fs0wk5oq.fsf@catern.com>
 <86edgfin4v.fsf@mail.linkov.net> <87o7fhixzv.fsf@catern.com>
 <86o7fhy9ae.fsf@mail.linkov.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
	logging-data="16837"; mail-complaints-to="usenet@ciao.gmane.io"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: Spencer Baugh <sbaugh@janestreet.com>, emacs-devel@gnu.org
To: Juri Linkov <juri@linkov.net>
Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 26 14:34:36 2023
Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>
Envelope-to: ged-emacs-devel@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 <emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org>)
	id 1r7FHP-00046H-CB
	for ged-emacs-devel@m.gmane-mx.org; Sun, 26 Nov 2023 14:34:36 +0100
Original-Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-devel-bounces@gnu.org>)
	id 1r7FGi-0005Xq-Dc; Sun, 26 Nov 2023 08:33:52 -0500
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 <bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com>)
 id 1r7FGg-0005Wp-Fq
 for emacs-devel@gnu.org; Sun, 26 Nov 2023 08:33:50 -0500
Original-Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1)
 (envelope-from <bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com>)
 id 1r7FGe-0008NP-5f
 for emacs-devel@gnu.org; Sun, 26 Nov 2023 08:33:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com;
 h=from:subject:in-reply-to:references:mime-version:to:cc:content-type:
 cc:content-type:from:subject:to;
 s=s1; bh=s7qt9MpmvwCdir3EwGzKyJw76Z2TnKzIse+BT3cGkHE=;
 b=WUE2R5VBeAJDZz+Jl9f1ochyR78OQlpghzeJTsb6/td4SvysiE6Hn8eZLw/qxlxSAZXO
 IQZhDTMN1bD/MgCgZn4d+9kuGqAbNpPSPRm3ZuPCG2F57wi092jfZ3sV6hU3m2Lx0qOxnd
 x2QWtUHPbkpstziP51/G4/q6fys7y462Wnz7g0hVMCLytk+S5WHPRQZ66gPKi4JqZrzq6p
 zAvif54CvXKhim6Q+cveLMk/CaQlUnPzcAO8QMtBXPb63HM+VdEF62IPdkRdkjo7j0rGhX
 HwFeAJpjfEkgPHsQcDrD8qMoOp1D5tqpFw2g6+lt8URaqvVcKcS/IU0D1gdCZgdg==
Original-Received: by filterdrecv-b85775b64-x9wz7 with SMTP id
 filterdrecv-b85775b64-x9wz7-1-65634939-E
 2023-11-26 13:33:45.821623391 +0000 UTC m=+3437566.507147984
Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-62 (SG) with ESMTP
 id yvFDuVruTb6864eIeQaIhw Sun, 26 Nov 2023 13:33:45.576 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=74.101.51.129;
 helo=localhost; envelope-from=sbaugh@catern.com; receiver=linkov.net 
Original-Received: from localhost (unknown [74.101.51.129])
 by earth.catern.com (Postfix) with ESMTPSA id AAA3C63672;
 Sun, 26 Nov 2023 13:33:12 +0000 (UTC)
In-Reply-To: <86o7fhy9ae.fsf@mail.linkov.net> (Juri Linkov's message of "Sat, 
 25 Nov 2023 20:31:21 +0200")
X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbIlOZJcm5LiGeRi=2Fjwujf?=
 =?us-ascii?Q?7tiBSEgJDlkRGtuuNF5edmAStPTw=2FKO1JdDonit?=
 =?us-ascii?Q?4vZWBTFvgo4jLqUHRyDBEpfvy02V0NZ3EUfo68t?=
 =?us-ascii?Q?uln0kHhA+cV8KU9WAjwXoXY7=2FOrtkbgrs+u378t?=
 =?us-ascii?Q?uLwt+tYx53HbzNmvxuRJViLDGrgQfu95VLg=3D=3D?=
X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q==
Received-SPF: pass client-ip=149.72.154.232;
 envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com;
 helo=s.wrqvwxzv.outbound-mail.sendgrid.net
X-Spam_score_int: 5
X-Spam_score: 0.5
X-Spam_bar: /
X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347,
 RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01,
 UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-devel>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
 <mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org
Xref: news.gmane.io gmane.emacs.devel:313239
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/313239>

--=-=-=
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Juri Linkov <juri@linkov.net> writes:
>>>>> I don't think this is realistic to add an individual option in all cases.
>>>>
>>>> That's not necessary.  We could also do possibility C that I described
>>>> before:
>>>>
>>>>>> C.
>>>>>> - Remove display-sort-function from the metadata
>>>>>> - add the 'read-kill category to the metadata
>>>>>> - add 'read-kill to completion-category-defaults
>>>>>> (diff is 3 lines)
>>>>
>>>> That seems simple and straightforward.
>>>
>>> Removing display-sort-function is still less safe
>>> than just adding a category.
>>
>> Why do you say that?
>>
>> The reason that comes to mind is that there are replacement completion
>> UIs which will need to explicitly add support for the category.  So
>> removing display-sort-function will affect them immediately, when they
>> might not yet have support for getting display-sort-function from
>> completion-category-defaults.
>>
>> That is true.
>>
>> But that actually suggests a further argument in this direction: if we
>> use user options which change the display-sort-function in the table
>> metadata, we'll have support for all completion UIs out of the box.
>>
>> That seems really desirable!  So maybe we do want a solution like A
>> where we add a user option?  Since that user option will work for all
>> completion UIs.
>>
>> Announcing "you can now customize the sorting order of a bunch of
>> completing-read-based things in this new way" but having that new way
>> only work for the default completion UI is a bit sad, although of course
>> they can support the new way eventually.
>
> This is what I believe they should do: we add a category,
> and they support it as well.

OK, I'm fine with that, but when we do that, I think the per-table
option should override the per-category option.

>>>>> I still don't understand why do you worry about this precedence when
>>>>> the user option completion-category-overrides is nil by default.
>>>>>
>>>>> Could you describe a use cases when such precedence might become a problem?
>>>>
>>>> If some table needs an individual option (because the sorting needs to
>>>> affect the completion generation), but the table shares a category with
>>>> other tables, then that individual option will be overridden by the
>>>> category configuration.
>>>
>>> Agreed, this is a problem.
>>>
>>>> For example, project-prompt-project-name allows one to complete over
>>>> project names.  If I wanted to sort its completions by some detail of
>>>> the underlying project (how recently the git repo was updated, maybe),
>>>> that would require the table to change behavior.  So it would need an
>>>> individual option.
>>>
>>> Or an individual subcategory.
>>>
>>>> However, project-prompt-project-name uses the same category as
>>>> project-find-file.  So if the user configured sorting for
>>>> project-find-file, it will override the table-specific option for
>>>> project-prompt-project-name.
>>>
>>> I believe they should use two different subcategories, e.g.
>>> 'project-file' and 'project-name'.
>>
>> I agree, but...
>>
>>>> I suppose another option is to simply declare that every table has to
>>>> have a unique category.  That would make "category" a misnomer though.
>>>
>>> Even such subcategories as 'project-name' make sense to use in other
>>> possible cases when reading a project name.
>>
>> ...if the project-name category is used for other tables too, but the
>> option is supposed to be specific to an individual completion table,
>> then we have the same problem again.
>
> And an alternative to add separate options to all these tables
> doesn't look more attractive.

Yes, but we don't have to do that, I'm OK with a category-based
approach.  I just think we should reserve the *ability* to use
table-specific options, by making a table-specific display-sort-function
override the category-specific display-sort-function.

Anyway, we're going around in circles a bit here.  How about this patch
which only adds the new historical option to completions-sort?  I think
we're in agreement on everything in this patch, and maybe installing it
will get some user feedback which we can use when coming back to this
later.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
 filename=0001-Add-historical-option-to-completions-sort.patch

>From c4435be3689278d380099f2341ac242bf74639df 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 historical option to completions-sort

Support sorting candidates in *Completions* by the order they show up
in the minibuffer history.

Also add minibuffer-sort-alphabetically and
minibuffer-sort-by-history, which are usable for both completions-sort
and display-sort-function.

* lisp/minibuffer.el (completions-sort): Document 'historical option.
(minibuffer-completion-help): Support 'historical option.
(minibuffer-sort-alphabetically)
(minibuffer-completion-base, minibuffer-sort-by-history): Add.
---
 lisp/minibuffer.el | 63 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 57 insertions(+), 6 deletions(-)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 5c12d9fc914..dfb30e4364c 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1314,14 +1314,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."
+Completion candidates in the *Completions* buffer are sorted
+depending on the value.
+
+If nil, sorting is disabled.
+If `alphabetical', candidates are sorted by
+`minibuffer-sort-alphabetically'.
+If `historical', candidates are sorted by
+`minibuffer-sort-by-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.
@@ -1647,6 +1659,43 @@ minibuffer--sort-preprocess-history
                      (substring c base-size)))
                  hist)))))
 
+(defun minibuffer-sort-alphabetically (completions)
+  "Sort COMPLETIONS alphabetically.
+
+COMPLETIONS are sorted alphabetically by `string-lessp'.
+
+This is a suitable function to use for `completions-sort' or to
+include as `display-sort-function' in completion metadata."
+  (sort completions #'string-lessp))
+
+(defvar minibuffer-completion-base nil
+  "The base for the current completion.
+
+This is the part of the current minibuffer input which is not
+being completed on.  This is primarily relevant for file names,
+where this is the directory component of the file name.")
+
+(defun minibuffer-sort-by-history (completions)
+  "Sort COMPLETIONS by their position in `minibuffer-history-variable'.
+
+COMPLETIONS are sorted first by `minibuffer-sort-alphbetically',
+then any elements occuring in the minibuffer history list are
+moved to the front based on the order they occur in the history.
+If a history variable hasn't been specified for this call of
+`completing-read', COMPLETIONS are sorted only by
+`minibuffer-sort-alphbetically'.
+
+This is a suitable function to use for `completions-sort' or to
+include as `display-sort-function' in completion metadata."
+  (let ((alphabetized (sort completions #'string-lessp)))
+    ;; Only use history when it's specific to these completions.
+    (if (eq minibuffer-history-variable
+            (default-value minibuffer-history-variable))
+        alphabetized
+      (minibuffer--sort-by-position
+       (minibuffer--sort-preprocess-history minibuffer-completion-base)
+       alphabetized))))
+
 (defun minibuffer--group-by (group-fun sort-fun elems)
   "Group ELEMS by GROUP-FUN and sort groups by SORT-FUN."
   (let ((groups))
@@ -2409,6 +2458,7 @@ minibuffer-completion-help
       (let* ((last (last completions))
              (base-size (or (cdr last) 0))
              (prefix (unless (zerop base-size) (substring string 0 base-size)))
+             (minibuffer-completion-base (substring string 0 base-size))
              (base-prefix (buffer-substring (minibuffer--completion-prompt-end)
                                             (+ start base-size)))
              (base-suffix
@@ -2473,7 +2523,8 @@ minibuffer-completion-help
                                             (funcall sort-fun completions)
                                           (pcase completions-sort
                                             ('nil completions)
-                                            ('alphabetical (sort completions #'string-lessp))
+                                            ('alphabetical (minibuffer-sort-alphabetically completions))
+                                            ('historical (minibuffer-sort-by-history completions))
                                             (_ (funcall completions-sort completions)))))
 
                       ;; After sorting, group the candidates using the
-- 
2.42.1


--=-=-=--