From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Possible minibuffer completion enhancements Date: Tue, 23 Jan 2024 09:00:12 +0100 Message-ID: <87ttn4iinn.fsf@daniel-mendler.de> References: <86v87l4xii.fsf@mail.linkov.net> <87a5ox7png.fsf@daniel-mendler.de> <871qa99kl3.fsf@daniel-mendler.de> Reply-To: Daniel Mendler Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31926"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Juri Linkov , Stefan Kangas , emacs-devel@gnu.org To: Eshel Yaron Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 23 09:01:32 2024 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 1rSBit-00086o-Gk for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jan 2024 09:01:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rSBi3-0007KL-2l; Tue, 23 Jan 2024 03:00:39 -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 1rSBht-0007Js-GH for emacs-devel@gnu.org; Tue, 23 Jan 2024 03:00:29 -0500 Original-Received: from server.qxqx.de ([2a01:4f8:c012:9177::1] helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rSBhg-0005G9-2s for emacs-devel@gnu.org; Tue, 23 Jan 2024 03:00:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DFszAHVquExSMVPhksJ2H46k2YSBJ19X9wizdjzCnH4=; b=o0TSHmkIjblPvBsfVBxLXMxzc7 reQuNus6U4yOKiSH8d25YUNm0EmFzWAxvADnWjQXxOox/4UILznp4xZCNfYy36Dzwt4JxGNHOGe/8 QjjGaKdyBQW6180qB+jnl3qdjW2H8BS46aWr/Jf+5P3SYrdTWREgfzOICmqbQJeosn88=; In-Reply-To: (Eshel Yaron's message of "Tue, 23 Jan 2024 08:04:34 +0100") Received-SPF: pass client-ip=2a01:4f8:c012:9177::1; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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-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:315245 Archived-At: Eshel Yaron writes: > Daniel Mendler writes: >>>> Regarding 5 and 6 it would be great to explore an alternative approach >>>> with a :property-function because of the additional flexibility and >>>> extensibility. We would get a lot of functionality for free. >>> >>> I think such an approach can leverage the infrastructure that my branch >>> implements, for example with a `narrow-completions-function` that uses >>> the properties you get from such a `property-function`, no? Also, I >>> agree that the approach you brought up could provide a lot of >>> functionality, but how would it be more flexible than the proposed >>> `narrow-completions-function` mechanism, where the completion table can >>> provide an arbitrary function? >> >> You are right that a narrow-completions-function could offer narrowing >> by property, and itself access the properties via a property-function. >> However a property-function is more generic since it will allow us to >> build more functionality in to the frontend without further extending >> the completion tables. >> >> I try to explain the idea a bit better. Instead of providing an >> annotation-function, a display-sort-function, a >> narrow-completions-function, a completion table could only provide a >> lower level property-function which provides metadata for each >> candidate. The completion tables would not have to provide the other >> functions anymore. >> >> The UI can query the properties of each candidate and format >> annotations, offer sorting and narrowing by properties. This leads to a >> separation of data backend (completion table) and presentation by the >> UI. The completion table itself is only responsible to provide the data >> (candidates and its properties), while the UI is responsible for >> presentation features, e.g., sorting or formatting and aligning the >> properties as annotations, etc. >> >> This means that a large fraction of the functionality will be part of >> the UI and has to be implemented there only once. The completion tables >> itself would be reduced to data backends, and we still get annotations, >> sorting, narrowing, and possible more property-dependent functionality. > > Thank you for the additional explanation! I find this approach > appealing, I just think it is not mutually exclusive with my changes: > even if completion tables would provide such a candidate-property > inspection facility, they'd still need to provide also the existing > completion metadata in favor of UIs that currently leverage that, right? > Also the new commands from my branch extend the vanilla completion UI, > and those would remain useful, hopefully, even if we later change how > they obtain the data they need from the backend (completion table). Absolutely. The changes are not mutually exclusive and the value of the UI enhancements can be evaluated independently. Nevertheless I think on the side of the completion table backends we should explore an approach where the completion tables provides data only and the UI reuses this data to implement various functions. A few more points to consider: 1. Changes to completion tables are pervasive, since many completion tables will be affected and have to be adapted if we extend them with new functionality. We can potentially save complexity if we chose the completion table extensions well. 2. If we add metadata extensions with overlapping purpose, e.g., a narrowing functions and after that some property function we end up with redundant code. 3. If the added functionality to completion tables is generic and not too tightly coupled with the UI, new possibilities open up. I had mentioned the Orderless completion style which could rely on a property-function to implement narrowing by property (not sure if this would also work with your narrow function). Also having the ability to create sorting functions and annotations from a single backend property function seems appealing, if it works. In your narrow-completions-function proposal, the narrowing functionality is a UI feature. The narrowing-completions-function even calls completing-read itself and I think we could do better if we make sure that the completion tables do not get extended with UI functionality, but stay lower level, only providing data. In this respect your narrowing-completions-function differs from existing metadata extensions, which are lower level and mostly pure non-interactive functions (for example the annotation-function or display-sort-function). > Anyway, if you or anybody else comes up with a (rough) sketch of this > alternative, I'd be glad to examine it and make a concrete comparison. Sure. However I am not interested in creating competing implementations which we then compare and ultimately scrap. I'd thought we could maybe consider a property function as an alternative (lower level, flexible) completion table extension and if possible, collaborate on such a design and rebase your UI enhancements on top of that, if you are open to that. I am not asking you to do all this work or throw yours away. I am rather asking if you would be interested in helping to explore such an alternative (for the completion table backends only), or if you think that a property-function is a flawed idea to begin with. Daniel