From: Juri Linkov <juri@linkov.net>
To: Spencer Baugh <sbaugh@catern.com>
Cc: Spencer Baugh <sbaugh@janestreet.com>, emacs-devel@gnu.org
Subject: Re: Updating *Completions* as you type
Date: Sat, 25 Nov 2023 20:31:21 +0200 [thread overview]
Message-ID: <86o7fhy9ae.fsf@mail.linkov.net> (raw)
In-Reply-To: <87o7fhixzv.fsf@catern.com> (Spencer Baugh's message of "Sat, 25 Nov 2023 16:44:50 +0000 (UTC)")
>>>> 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.
This is what I believe they should do: we add a category,
and they support it as well.
>>> 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'm still not convinced that a user option is needed for such minor thing.
>>>> 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.
And an alternative to add separate options to all these tables
doesn't look more attractive.
next prev parent reply other threads:[~2023-11-25 18:31 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 23:53 Updating *Completions* as you type sbaugh
2023-10-13 6:31 ` Eli Zaretskii
2023-10-13 18:01 ` Spencer Baugh
2023-10-14 7:09 ` Eli Zaretskii
2023-10-14 19:26 ` Björn Bidar
[not found] ` <874jit2ef7.fsf@>
2023-10-14 19:38 ` Eli Zaretskii
2023-10-14 16:51 ` Juri Linkov
2023-10-14 17:56 ` sbaugh
2023-10-14 19:51 ` Dmitry Gutov
2023-10-13 6:34 ` Juri Linkov
2023-10-13 19:04 ` Spencer Baugh
2023-10-14 16:58 ` Juri Linkov
2023-10-14 20:05 ` sbaugh
2023-10-15 6:06 ` Eli Zaretskii
2023-10-15 15:55 ` sbaugh
2023-10-16 11:38 ` Eli Zaretskii
2023-10-16 14:50 ` Michael Albinus
2023-10-16 15:58 ` [External] : " Drew Adams
2023-10-16 12:16 ` sbaugh
2023-10-17 18:23 ` Juri Linkov
2023-10-18 23:27 ` Spencer Baugh
2023-10-15 7:32 ` Juri Linkov
2023-10-16 19:28 ` Rudolf Adamkovič
2023-10-17 18:38 ` Juri Linkov
2023-10-15 20:31 ` Eshel Yaron
2023-10-16 3:18 ` [External] : " Drew Adams
2023-10-16 16:54 ` Juri Linkov
2023-10-17 13:48 ` sbaugh
2023-10-17 18:35 ` Juri Linkov
2023-10-17 22:57 ` Spencer Baugh
2023-10-18 3:04 ` [External] : " Drew Adams
2023-10-18 6:56 ` Juri Linkov
2023-10-18 12:25 ` Spencer Baugh
2023-10-18 17:32 ` Juri Linkov
2023-10-18 23:33 ` Spencer Baugh
2023-10-19 2:29 ` Spencer Baugh
2023-10-19 6:55 ` Juri Linkov
2023-11-19 19:22 ` sbaugh
2023-11-20 7:51 ` Juri Linkov
2023-11-20 15:24 ` Spencer Baugh
2023-11-20 17:47 ` Juri Linkov
2023-11-20 18:50 ` Spencer Baugh
2023-11-21 7:58 ` Juri Linkov
2023-11-21 12:40 ` sbaugh
2023-11-21 17:09 ` Juri Linkov
2023-11-21 20:45 ` Spencer Baugh
2023-11-22 7:51 ` Juri Linkov
2023-11-22 16:11 ` Spencer Baugh
2023-11-23 7:58 ` Juri Linkov
2023-11-23 12:36 ` sbaugh
2023-11-24 7:58 ` Juri Linkov
2023-11-25 16:44 ` Spencer Baugh
2023-11-25 18:31 ` Juri Linkov [this message]
2023-11-26 13:33 ` sbaugh
2023-11-27 7:28 ` Juri Linkov
2023-11-28 14:38 ` Spencer Baugh
2023-11-28 15:03 ` Eli Zaretskii
2023-11-28 17:13 ` Juri Linkov
2023-11-28 17:36 ` Eli Zaretskii
2023-11-29 7:11 ` Juri Linkov
2023-11-29 13:09 ` Eli Zaretskii
2023-11-29 14:14 ` Spencer Baugh
2023-11-29 14:54 ` Eli Zaretskii
2023-11-29 15:21 ` Spencer Baugh
2023-11-29 15:52 ` Eli Zaretskii
2023-11-29 19:17 ` Spencer Baugh
2023-11-30 6:12 ` Eli Zaretskii
2023-11-30 12:33 ` Spencer Baugh
2023-11-30 14:10 ` Eli Zaretskii
2023-11-28 23:56 ` Spencer Baugh
2023-11-29 3:33 ` Eli Zaretskii
2023-12-03 17:25 ` Juri Linkov
2023-12-03 17:56 ` Eli Zaretskii
2023-12-06 17:17 ` Juri Linkov
2023-11-28 17:16 ` Juri Linkov
2023-11-28 23:36 ` Turning completion table lambdas into symbols Spencer Baugh
2023-11-28 23:51 ` Dmitry Gutov
2023-11-29 19:26 ` Spencer Baugh
2023-12-01 0:36 ` Dmitry Gutov
2023-11-29 7:18 ` Juri Linkov
2023-11-21 12:54 ` Updating *Completions* as you type John Yates
2023-11-21 17:03 ` Juri Linkov
2023-11-21 22:27 ` John Yates
2023-10-20 6:49 ` Juri Linkov
2023-10-17 15:01 ` sbaugh
2023-10-17 18:20 ` Juri Linkov
2023-10-17 23:37 ` Spencer Baugh
2023-10-17 23:44 ` Spencer Baugh
2023-10-18 6:51 ` Juri Linkov
2023-10-18 12:47 ` Spencer Baugh
2023-10-18 17:28 ` Juri Linkov
2023-10-18 23:32 ` Spencer Baugh
2023-10-16 3:19 ` [External] : " Drew Adams
2023-10-20 9:35 ` zcomplete Philip Kaludercic
2023-10-22 17:28 ` zcomplete Juri Linkov
2023-10-23 5:00 ` zcomplete Protesilaos Stavrou
2023-10-23 6:45 ` zcomplete Juri Linkov
2023-10-13 18:11 ` Updating *Completions* as you type Daniel Semyonov
2023-10-13 18:48 ` Spencer Baugh
2023-10-16 3:16 ` [External] : " Drew Adams
2023-10-16 9:25 ` Philip Kaludercic
2023-10-16 16:03 ` Drew Adams
2023-10-20 7:45 ` Philip Kaludercic
2023-10-20 16:10 ` Drew Adams
2023-10-16 22:55 ` Emanuel Berg
2023-10-17 6:09 ` Emanuel Berg
2023-10-17 0:44 ` Michael Heerdegen
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o7fhy9ae.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@catern.com \
--cc=sbaugh@janestreet.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.