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: Tue, 21 Nov 2023 12:40:35 +0000 Message-ID: <87pm03jn3w.fsf@catern.com> References: <87bkd3z9bi.fsf@catern.com> <86cyxjyr1y.fsf@mail.linkov.net> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24706"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:ota1cmS6fMx13cN7Nfxes6iDXuI= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 21 13:46:01 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 1r5Q8f-00069p-5A for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Nov 2023 13:46:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5Q7z-0004nu-69; Tue, 21 Nov 2023 07:45:20 -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 1r5Q3r-0002tK-8b for emacs-devel@gnu.org; Tue, 21 Nov 2023 07:41:03 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5Q3p-00007m-Ea for emacs-devel@gnu.org; Tue, 21 Nov 2023 07:41:03 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1r5Q3m-0009tT-Dg for emacs-devel@gnu.org; Tue, 21 Nov 2023 13:40:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 21 Nov 2023 07:45:13 -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:313109 Archived-At: Juri Linkov writes: >> I expect some disagreement about the following question: should >> completion-category-overrides override the display-sort-function >> returned by the completion table? That is, should it instead be: >> >> (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) > > I think this is the most correct precedence since the users should be > able to override the function call metadata. We have an analogous > priority levels for 'display-buffer': > > 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 > > Since completion-category-overrides is a user option > it corresponds to display-buffer-alist. > And completion-category-defaults looks like > display-buffer-base-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. That's not true with display-buffer. The only configuration mechanism is display-buffer-alist. - 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.) - 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. - 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. - The "overrides" in "completion-category-overrides" is just a name. It doesn't mean that we have to make it override everything else. I suppose we could add a new completion-category-table-overrides, if we find a use case for making the category override the table but it's rare. That's starting to reach the complexity of display-buffer-alist though... 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.