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: Sat, 25 Nov 2023 16:44:50 +0000 (UTC) Message-ID: <87o7fhixzv.fsf@catern.com> References: <87bkd3z9bi.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> <86leao519y.fsf@mail.linkov.net> <87fs0wk5oq.fsf@catern.com> <86edgfin4v.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12466"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Spencer Baugh , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 25 17:45:46 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 1r6vmr-00030f-HA for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Nov 2023 17:45:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r6vm4-0006De-2g; Sat, 25 Nov 2023 11:44:56 -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 1r6vm3-0006DV-45 for emacs-devel@gnu.org; Sat, 25 Nov 2023 11:44:55 -0500 Original-Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r6vm0-0004vE-AD for emacs-devel@gnu.org; Sat, 25 Nov 2023 11:44:54 -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: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=BGegdhFfsAUq8gP3bvlCqPmnHP4nzFwEKlM2crdbqWw=; b=mL6c0PhSz6kzG1XKxBRNO+iUah9GlSKJSfNQy9dUQ5qly8V/c7X11xZdYwqjBX1d3C0J 9XKfso9IxiycEpvw8dD916DHfHTS5rGoInB6xIDfoVsiz+xxk+9bZN3/Gts8cdrSGT2VkM bPpxjtrWOJ+c7FSlD9AHoFgJ03MmZcJzG+qlzi8XkofUIHmEFTqx+I9bkCrb7v6TCA3OZQ m7YoNnjPpnXcE44qhrcyVWsG5LZwDpEFGsH7Wh4gaHI/VE+3dSpJpoOiSJ6G0wWVYxtrHp niYsiOM4d5lshD/xw/fEWNm3Ps2WEdfdcbzQ7lRnm19VoIKo5UTDXjj9uWZ0BdTA== Original-Received: by filterdrecv-5bbdbb56cd-pfcrq with SMTP id filterdrecv-5bbdbb56cd-pfcrq-1-65622482-3F 2023-11-25 16:44:50.876900862 +0000 UTC m=+3362702.683805185 Original-Received: from earth.catern.com (unknown) by geopod-ismtpd-19 (SG) with ESMTP id pi0wC-dARR2IK2oZtHCE2w Sat, 25 Nov 2023 16:44:50.821 +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 0D13F6359D; Sat, 25 Nov 2023 16:44:20 +0000 (UTC) In-Reply-To: <86edgfin4v.fsf@mail.linkov.net> X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCgnDOGx9aNacvGlztt?= =?us-ascii?Q?w7KSTyEc0nIdWpyKT9E5LMGVgA8ONLf1t2plkpE?= =?us-ascii?Q?v0uWt69Hetgt3KUNSS+KSv1exmsN3nOR9T=2FNM2w?= =?us-ascii?Q?aS=2F8P524TzIdWANM6l6ghx8gkKSRedULoe63dvB?= =?us-ascii?Q?Xl3ekKlHdEZqFbvjqlC+EdVRX8eQUoWn186WCy?= X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Received-SPF: pass client-ip=149.72.126.143; envelope-from=bounces+21787432-489d-emacs-devel=gnu.org@em8926.catern.com; helo=s.wrqvtzvf.outbound-mail.sendgrid.net X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 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, 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." 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:313214 Archived-At: Juri Linkov 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. >> Identity obviously keeps the original order, but what is the original >> order? That is not documented anywhere and I don't think it's >> intuitive. The user can always just try it and see, but that's a poor >> substitute for documentation. > > In these rare cases when the default order is not intuitive, > this can be explained in the docstring of the command that uses > 'completing-read', e.g. in the docstring of 'read-from-kill-ring'. Hm, I do think the wording on that would be a bit tricky. Since *actually* the default behavior today is alphabetical sorting. We would want to say "if completions-sort is nil, read-buffer completions are in buffer-list order". I guess it's not too bad, but we also need to document the category symbol. And perhaps the version it was added in. All together it still seems to me that it would be better to just mention 'read-from-kill-ring-sort' in the docstring of 'read-from-kill-ring'. >>> 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.