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: Tue, 21 Nov 2023 15:45:20 -0500 Message-ID: References: <87bkd3z9bi.fsf@catern.com> <86r0lxm7um.fsf@mail.linkov.net> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38305"; 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 04:29:17 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 1r5dvQ-0009lW-Mi for ged-emacs-devel@m.gmane-mx.org; Wed, 22 Nov 2023 04:29:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5dud-0008PK-4j; Tue, 21 Nov 2023 22:28:27 -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 1r5Xcd-0005wf-EQ for emacs-devel@gnu.org; Tue, 21 Nov 2023 15:45:27 -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 1r5XcZ-0000Xw-HT for emacs-devel@gnu.org; Tue, 21 Nov 2023 15:45:25 -0500 In-Reply-To: <861qcjw3ch.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 21 Nov 2023 19:09:02 +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: Tue, 21 Nov 2023 22:28:26 -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:313126 Archived-At: Juri Linkov writes: >>>> (or >>>> (alist-get 'display-sort-function (alist-get category completion-category-overrides)) >>>> (alist-get 'display-sort-function metadata) >>>> (alist-get 'display-sort-function (alist-get category completion-category-defaults)) >>>> completions-sort) >>> >>> 1. display-buffer-overriding-action >>> 2. display-buffer-alist >>> 3. function call arguments that correspond to completion metadata >>> 4. display-buffer-base-action >>> 5. display-buffer-fallback-action >> >> A few points in favor of >> >> (alist-get 'display-sort-function metadata) >> (alist-get 'display-sort-function (alist-get category completion-category-overrides)) >> >> instead: >> >> - 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. >> That's not true with display-buffer. The only configuration >> mechanism is display-buffer-alist. > > Actually several user options already exist for display-buffer such as > display-comint-buffer-action and display-tex-shell-buffer-action. > They cover a whole category of display-buffer calls that display > all types of comint buffers, etc. So these options correspond > to completion categories, not to individual completion tables. Interesting. It looks like those user options configure a broad category, as you say, and they do this by changing the ACTION function call argument in various places. So, those user options configure a broad category, and then more specific configuration overrides that broad category. I suppose that's what I also suggest for completion sorting. >> - Given that the user can still configure the display-sort-function, I >> don't see any use case where the user should override it. (A buggy >> completion table that returns the wrong display-sort-function? But >> that should just be fixed.) > > I don't understand how the user can configure the display-sort-function, > please elaborate. If a completion table specifies a display-sort-function in its metadata, it should have a user option to configure that display-sort-function. >> - display-buffer-alist is driven purely by buffer-match-p conditions, so >> there's a linear sequence of overriding. The display-sort-function >> has two levels: the completion table and the completion category. >> Since the table is more specific than the category, it should override >> the category. > > Agreed. But this means only one thing that a user option > for an individual completion table should take precedence > over completion-category-overrides. 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? So then we're only disagreeing over whether such options should exist? >> - As a minor point, I, and many other Emacs users IME, find the >> display-buffer configuration to be complex and hard to use, so I don't >> think we should try to emulate it too much. > > What is an alternative? A myriad of individual options? For display-buffer configuration? I'm not sure, I don't want to get into it too much. For completion sorting configuration, though, I'm not suggesting adding many individual options. I'm quite happy with the proposal of, "categories can determine the display-sort-function, and then options for individual completion tables will override that". In that world, there would be a read-buffer-sort option - but it would be nil by default, so the read-buffer completion table by default wouldn't specify a display-sort-function. And the user could configure read-buffer completion sorting using completion-category-overrides however they like; and if they set read-buffer-sort to something else, then it will in turn override the category-based configuration. 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. >> Alternatively, could we just add support for configuring the individual >> table now, and add category-based configuration later? We don't need to >> add everything all at once, and that will give us valuable user >> feedback. > > 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. 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. 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))) instead of adding a category 'kill-ring and sticking that into completion-category-defaults.