From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh <sbaugh@janestreet.com> Newsgroups: gmane.emacs.devel Subject: Re: Updating *Completions* as you type Date: Mon, 20 Nov 2023 13:50:37 -0500 Message-ID: <iercyw445tu.fsf@janestreet.com> References: <87bkd3z9bi.fsf@catern.com> <86cyxjyr1y.fsf@mail.linkov.net> <ier34ye4a3x.fsf@janestreet.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> <ierleas4fcr.fsf@janestreet.com> <86v89ws5t3.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="3593"; 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 <juri@linkov.net> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 20 20:15:03 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 1r59ja-0000fh-7t for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Nov 2023 20:15:02 +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 1r59im-0001q9-05; Mon, 20 Nov 2023 14:14:12 -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 <sbaugh@janestreet.com>) id 1r59ME-0002Al-71 for emacs-devel@gnu.org; Mon, 20 Nov 2023 13:50:54 -0500 Original-Received: from mxout1.mail.janestreet.com ([38.105.200.78]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sbaugh@janestreet.com>) id 1r59MB-0001qX-Cb for emacs-devel@gnu.org; Mon, 20 Nov 2023 13:50:53 -0500 In-Reply-To: <86v89ws5t3.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 20 Nov 2023 19:47:12 +0200") Received-SPF: pass client-ip=38.105.200.78; envelope-from=sbaugh@janestreet.com; helo=mxout1.mail.janestreet.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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: Mon, 20 Nov 2023 14:14:09 -0500 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:313070 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/313070> Juri Linkov <juri@linkov.net> writes: >> For buffers, for example, sorting by the buffer-list can be done by just >> setting display-sort-function to identity, but we probably shouldn't >> expose that fact to the user. (We could expose a generic "sort by >> defaults" but that would be less efficient.) > > It should be fine to use 'identity' as a value when the Customization UI > will show a more meaningful tag like "Unsorted". Yes, that's fine. But "Unsorted" is different from "Sorted by buffer-list", which is the behavior one gets with read-buffer. In other words, the documentation can be more specific for read-buffer-sort. >> The sorting style might even require the sorting option to actually >> change the completion table's behavior. File name completion could be >> sorted by mtime, for example, by having the completion table include >> mtime as a text property when read-file-name-sort=mtime, and then >> setting display-sort-function to something which reads that property. I >> think that can only work if we have separate sorting options. > > Also a separate option might be needed when a completion table > supports a non-standard sorting order such as > 'mule--ucs-names-sort-by-code' when 'read-char-by-name-sort' > is customized to 'code'. But the users still should have freedom > to override all metadata: display-sort-function, affixation-function, > group-function, etc. > >>> (setopt completion-category-overrides >>> '((buffer (display-sort-function . minibuffer-sort-by-history)) >>> (project-file (display-sort-function . minibuffer-sort-by-history)) >>> >>> And default values could be specified in completion-category-defaults. >> >> I think the default values would be part of the completion table itself; >> a completion table can just set display-sort-function itself, it doesn't >> need completion-category-defaults to do that. > > OTOH, the completion table needs only to return its category in metadata. > Otherwise every completion table of the same category would need to > duplicate display-sort-function in its completing-read. Interesting point. In some sense, the category gives us an inheritance mechanism for completion tables, where a completion table can just use the defaults for its category rather than specifying all the details. But if the completion table has some specific sorting function it wants, it can provide that by explicitly returning it in the metadata. And completion-category-overrides gives the user a way to do customization of the category defaults. So perhaps, for a given metadata, display-sort-function would be: (or (alist-get 'display-sort-function metadata) (alist-get 'display-sort-function (alist-get category completion-category-overrides)) (alist-get 'display-sort-function (alist-get category completion-category-defaults)) completions-sort) That makes sense to me. And (alist-get 'display-sort-function metadata) is configurable with separate completion-table-specific options, like read-buffer-sort. If we do this, completions-sort acts like a "default" entry in completion-category-defaults, which acts for categories which aren't otherwise matched. Which makes a lot of sense, and makes it behave like completion-styles and completion-cycle-threshold. 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 no. The most specific customization (customizing an individual completion table) should override more broad customizations (customizing an entire category). I don't think there's a reasonable use-case for overriding a display-sort-function explicitly returned by a table - we can just make that display-sort-function configurable directly. We probably will want to make this clear in the documentation, of course. >> Maybe we should decide what things are supposed to be configured by >> category and what things are supposed to be configured by the table >> itself. Because in theory we could allow setting completion-styles and >> completion-cycle-threshold with completion table metadata, and I'm not >> sure why we didn't do it that way - it could even be nice to have a >> completion style which is specific to an individual completion table. > > I guess when an individual completion table needs to use metadata > slightly different from other similar cases then it should provide > a different category/subcategory. Or the individual completion table just returns that slightly different metadata itself, and it overrides the metadata pulled from its category.