unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eshel Yaron <me@eshelyaron.com>
To: Daniel Mendler <mail@daniel-mendler.de>
Cc: Stefan Kangas <stefankangas@gmail.com>,
	 Juri Linkov <juri@linkov.net>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	 emacs-devel@gnu.org
Subject: Re: Possible minibuffer completion enhancements
Date: Sun, 21 Jan 2024 15:49:39 +0100	[thread overview]
Message-ID: <m1wms22130.fsf@dazzs-mbp.home> (raw)
In-Reply-To: <87edeboslq.fsf@daniel-mendler.de> (Daniel Mendler's message of "Sun, 21 Jan 2024 12:04:17 +0100")

Daniel Mendler <mail@daniel-mendler.de> writes:

> Eshel Yaron <me@eshelyaron.com> 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



  reply	other threads:[~2024-01-21 14:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-14 17:28 Possible minibuffer completion enhancements Eshel Yaron
2024-01-15 12:19 ` Eli Zaretskii
2024-01-16 13:47   ` Eshel Yaron
2024-01-16 14:10     ` Eli Zaretskii
2024-01-17 18:57       ` Eshel Yaron
2024-01-15 21:35 ` Stefan Kangas
2024-01-16 13:58   ` Eshel Yaron
2024-01-16 22:44     ` Stefan Kangas
2024-01-17 19:17       ` Eshel Yaron
2024-01-17 21:17         ` Stefan Kangas
2024-01-19 12:31           ` Eshel Yaron
2024-01-21  9:03             ` Eshel Yaron
2024-01-21 11:04               ` Daniel Mendler via Emacs development discussions.
2024-01-21 14:49                 ` Eshel Yaron [this message]
2024-01-22  7:50               ` Juri Linkov
2024-01-22  8:12                 ` Daniel Mendler via Emacs development discussions.
2024-01-22 12:18                   ` Eshel Yaron
2024-01-22 12:35                     ` Eshel Yaron
2024-01-23  8:08                       ` Daniel Mendler via Emacs development discussions.
2024-01-22 20:31                     ` Daniel Mendler via Emacs development discussions.
2024-01-23  7:04                       ` Eshel Yaron
2024-01-23  8:00                         ` Daniel Mendler via Emacs development discussions.
2024-01-23 16:23                           ` Eshel Yaron
2024-01-23 18:32                             ` Daniel Mendler via Emacs development discussions.
2024-01-24  2:32                   ` Madhu
2024-01-22 21:11               ` Philip Kaludercic
2024-01-23  7:33                 ` Eshel Yaron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1wms22130.fsf@dazzs-mbp.home \
    --to=me@eshelyaron.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@linkov.net \
    --cc=mail@daniel-mendler.de \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).