From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron Newsgroups: gmane.emacs.devel Subject: Re: Possible minibuffer completion enhancements Date: Sun, 21 Jan 2024 15:49:39 +0100 Message-ID: References: <87edeboslq.fsf@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26121"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Kangas , Juri Linkov , Stefan Monnier , emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 21 15:50:14 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 1rRZ9K-0006aO-J1 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jan 2024 15:50:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rRZ8r-0005iq-6m; Sun, 21 Jan 2024 09:49:45 -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 1rRZ8q-0005ib-Bp for emacs-devel@gnu.org; Sun, 21 Jan 2024 09:49:44 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16] helo=eshelyaron.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rRZ8o-0005H0-MT for emacs-devel@gnu.org; Sun, 21 Jan 2024 09:49:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1705848581; bh=7kqj1fzoJHTWhi/RhVd3A7txCiXxBFaUp0k+N3QplaM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tCwYMB1YTSLcsrMjsTo3JvLKGHvoYfo6nkbNAjcNHEqdyivCsA7AWas/jN+mpogKM yJwsytmhGmxwrcV2fKb4r9xSi4xtJSz5a+LVMbdRvlnZKl97HfczKCwjM2atC2bmfq +RrGPJTAMZs0vYgt0FkL/HP+0Q/0ASIeKuuFNRFWYQqxGP5lWSyXM+VyxcLnPFM8Po y7BkBb+B32WuJttC7fB074cDkd3rUA7HbPuyBYfG7JJgOZ2PtM2WBZmLxRmlcKC/o1 yMniz7v1vLIKb/Sh/lYGzNCu0A32Ir49gjRv0yxuzqvyIcbwV5/NPQ1YSjX0NrwXyx VoNk1esHadmAg== In-Reply-To: <87edeboslq.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sun, 21 Jan 2024 12:04:17 +0100") X-Hashcash: 1:20:240121:stefankangas@gmail.com::Xz2Rm3rTjRHY0HNM:1Eap X-Hashcash: 1:20:240121:juri@linkov.net::QpqWHQ6ICSKQwrkX:0o9X X-Hashcash: 1:20:240121:emacs-devel@gnu.org::+xyTAVDGfsY27XyE:U6B X-Hashcash: 1:20:240121:mail@daniel-mendler.de::IJpXLFoX87X1k5px:4Dga X-Hashcash: 1:20:240121:monnier@iro.umontreal.ca::/6+W91gGLFCLEaE/:2513 Received-SPF: pass client-ip=107.175.124.16; envelope-from=me@eshelyaron.com; helo=eshelyaron.com 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:315178 Archived-At: Daniel Mendler writes: > Eshel Yaron writes: >> >> I've rebased the feature/minibuffer-completion-enhancements branch on >> top of the current master, and pushed it to emacs.git. Looking forward >> for your thoughts and feedback! > > Thanks. I took a look at your enhancements Thank you! > and I thought one could even go a step further (for the narrowing and > sorting) by adding a generalized and unified completion candidate > :property-function. > > This function takes a candidate (or a list of candidates as argument) > and returns a list of properties, characterizing the candidate. For > files the property function could for example return mode, owner, > group, size and last modification date. Similarly, for buffers > possible properties would be the modification status, the size and the > mode. > > Then these properties could be used for: > > - Sorting: Add a command to sort the candidates by property field. A > comparator function is needed for this to work, maybe based on the > property type and cl-defgeneric. > > - Annotations: Each of the properties could be displayed in a column > view as annotations. A mechanism (again possibly via cl-defgeneric) is > needed to transform a property value to its string representation. > > - Narrowing/Filtering: A completion style could take the properties and > handle a query language with space-separated input, similar to the > Orderless completion style, e.g., @mode=lisp. Alternatively a modified > minibuffer-completion-predicate could be installed, similar to your > narrow-completions-function. I had similar thoughts while working on some of these things, and I agree that a standard way for the UI to obtain a set of relevant properties/attributes of the completion candidates would be an interesting next step. My changes already allow you to sort and filter by properties that are particular to some set of completions candidates (for example you can sort file completions by last modified time with `C-x C-v m` in the minibuffer), but a standard way to inspect candidate attributes would let us provide many more such specialized sorting and filtering options in many more cases. > Generally I find it a bit difficult to browse through your changes, > since they are slightly mixed. There are many ideas here and this may > make it harder to discuss the changes. Maybe you could reorder the > commits more logically or create separate branches for separate > additions. Are there any parts that you found particularly difficult to review? Perhaps I could provide more insight. I've made an effort to provide some reasoning behind every change in the commit messages, and I also tried to reorder some commits when I created this branch, but rewriting history with many overlapping changes proved quite challenging, and I didn't think it was cost-efficient. > A few of the changes go in the direction of technical changes unrelated > to the UI changes, which in my opinion would be good additions: > > - completion-table-with-metadata: I've written (or seen) similar helpers > many times in packages, so the addition of such helpers would reduce > code duplication and simplify completion table construction. Yes, that's really handy. > A while ago I had also proposed an even simpler addition of a > completion-table-with-category helper which makes it possible to > only override the completion category. This functionality is useful > given that one often wants to specify the candidate category, in > particular given the recent enhancements by Juri, which added > category-based overrides via completion-category-overrides. Indeed, with `completion-table-with-metadata` this is reduced to: --8<---------------cut here---------------start------------->8--- (completion-table-with-metadata table '((category . completion-style))) --8<---------------cut here---------------end--------------->8--- > - The idea to rewrite the CRM functionality looks sound to me. I always > wondered why CRM is not going through plain completing-read. Were > there specific reasons for the current approach? Maybe Stefan Monnier > has some insights on this? I don't know, I'd appreciate any input from Stefan, of course. Thanks again for reviewing, Eshel