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