From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.devel Subject: Re: Updating *Completions* as you type Date: Wed, 22 Nov 2023 11:11:15 -0500 Message-ID: References: <87bkd3z9bi.fsf@catern.com> <87sf6dx954.fsf@catern.com> <87ttqpwea9.fsf@catern.com> <86wmvlw178.fsf@mail.linkov.net> <87bkcwx3ft.fsf@catern.com> <86y1g076vh.fsf@mail.linkov.net> <87sf68unh1.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> <86v89ws5t3.fsf@mail.linkov.net> <86v89vzf1o.fsf@mail.linkov.net> <87pm03jn3w.fsf@catern.com> <861qcjw3ch.fsf@mail.linkov.net> <86r0ki2on3.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="37351"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: sbaugh@catern.com, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 22 17:33:41 2023 Return-path: 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 ) id 1r5qAX-0009Ta-Jp for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Nov 2023 17:33:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5q9e-0006PK-Ab; Wed, 22 Nov 2023 11:32:46 -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 ) id 1r5pot-0001LZ-5R for emacs-devel@gnu.org; Wed, 22 Nov 2023 11:11:19 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5por-00020w-AN for emacs-devel@gnu.org; Wed, 22 Nov 2023 11:11:18 -0500 In-Reply-To: <86r0ki2on3.fsf@mail.linkov.net> (Juri Linkov's message of "Wed, 22 Nov 2023 09:51:44 +0200") Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 22 Nov 2023 11:32:44 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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:313131 Archived-At: Juri Linkov writes: >>>> - Again, the user is still able to configure the display-sort-function >>>> by configuring the individual completion table. >>> >>> Does this mean that every individual completion table should have >>> a separate user option? >> >> No: only the completion tables which specify a display-sort-function in >> their metadata. All such completion tables should have a user option to >> configure that display-sort-function. > > How then users could change the sorting order for individual tables > that don't specify a display-sort-function to use an order different > from completions-sort? They can use the category if the table specifies one. If the table neither specifies a category nor provides a table-specific option, the display sort function for that table isn't currently configurable. Which I think we're both fine with? So: we already accept that for some completion tables, it won't be possible to customize their display sort function out of the box. >> Well, yes. So then we agree that a user option for an individual >> completion table, if it exists, should take precedence over >> completion-category-overrides? > > The problem is that we can't distinguish two cases: > > 1. when display-sort-function is hard-coded in metadata > by the author of the completion table; > 2. when display-sort-function in metadata > gets the value from the user option. I think we should just eliminate any instances of case 1. Case 1 just means the completion table's display sort function isn't currently configurable. Which I think we've already accepted will be the case for some tables, until we go and make them configurable either by adding a table-specific option, adding a category, or both. > Since we can't distinguish these cases, then it makes more sense > when completion-category-overrides overrides everything: > > (alist-get 'display-sort-function (alist-get category completion-category-overrides)) > (alist-get 'display-sort-function metadata) ;; metadata with/out individual options > (alist-get 'display-sort-function (alist-get category completion-category-defaults)) > > There is no problem with this because completion-category-overrides > is a user option as well, so everything still is under user control. Only if the completion table specifies a category. Which most do not. So we'd need to change it to specify a category. And if we're doing that, we could also change it to not hard-code a display-sort-function at the same time. That is, for any tables where the display-sort-function is currently hardcoded, we can add a category, and remove the hardcoded display-sort-function from the table metadata, and add the display-sort-function to completion-category-defaults. >> So then we're only disagreeing over whether such options should exist? > > Yes, I think we should add individual options only in exceptional cases. > >> These individual options would also provide a natural place to document >> behavior like "if you configure the display-sort-function for buffer >> completion to 'identity, then the buffer sort order will match >> (buffer-list)". But the user could still make use of that information >> by configuring the category. > > I agree that an option with documentation could help in such cases > when a non-trivial sorting function is provided for a completion table. > >>> I see no need to add individual options as all. Every completion table >>> that significantly differs from other tables so that it needs a separate >>> display-sort-function, could provide a separate category. For example, >>> there is a category 'buffer'. If 'switch-to-buffer' needs another >>> display-sort-function it could provide a category 'buffer-for-switching'. >> >> That won't work with the scenario I described before with sorting >> file-name completion by mtime, where changing the sorting requires also >> changing the completion table. > > I agree that individual options are required in such rare cases when > their values affect the completion table and its formatting. OK, I think I can agree with that, if we agree that in those rare cases, the individual options should take precedence over the category-based configuration. >> Also, this would require adding a category for essentially every >> completion table. For example, I see that read-from-kill-ring specifies >> a display-sort-function, currently set to 'identity. > > It's much simpler to add an extra line with a category. > >> If we wanted to make that configurable, it seems much easier to just do >> >> (if (eq action 'metadata) >> ;; Keep sorted by recency >> - '(metadata (display-sort-function . identity)) >> + `(metadata (display-sort-function . ,read-from-kill-ring-sort)) >> (complete-with-action action completions string pred))) > > This is an incomplete patch, there should be also a dozen of lines > with defcustom, its docstring, the version number and a list > of choices, etc. And all this for a very small percent of users > who would like to change this order. This is too wasteful. > It would be much more efficient to allow doing the same > by customizing completion-category-overrides. The docstring and list of choices for read-from-kill-ring-sort are something we want anyway - we would like to document that 'identity for read-for-kill-ring keeps the kill ring sorted by recency, for example. I see no better place to document that. The version number is also something we want anyway: if we just add a category to read-from-kill-ring in Emacs 30, this will work only in Emacs 30 and not in Emacs 29, and there's no way for a user to know that other than by reading NEWS. For such tables, I see three good possibilities (in order of my own preference): A. - Add read-from-kill-ring-sort defaulting to identity (with docstring) (diff is 1 line + defcustom) B. - Add read-from-kill-ring-sort defaulting to nil (with docstring) - add the 'read-kill category to the metadata - add 'read-kill to completion-category-defaults (diff is 3 lines + defcustom) 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) If you really don't want the defcustom and associated documentation, I'm OK with C. The option which I think is not good is: D. - add the 'read-kill category to the metadata - make completion-category-overrides take precedence over what is specified in the table metadata (diff is 1 line) This is a slightly smaller diff than option C, but I think it's a fundamentally worse approach than C, because in the rare cases where we do want an individual option for the table, we won't have a way for that option to take precedence over the broader category-based configuration.