Re: Updating *Completions* as you type

[Juri Linkov]

>>> (or
>>>  (alist-get 'display-sort-function (alist-get category 
>>> completion-category-overrides))
>>>  (alist-get 'display-sort-function metadata)
>>>  (alist-get 'display-sort-function (alist-get category 
>>> completion-category-defaults))
>>>  completions-sort)
>>
>> 1. display-buffer-overriding-action
>> 2. display-buffer-alist
>> 3. function call arguments that correspond to completion metadata
>> 4. display-buffer-base-action
>> 5. display-buffer-fallback-action
>
> A few points in favor of
>
>   (alist-get 'display-sort-function metadata)
>   (alist-get 'display-sort-function (alist-get category 
> completion-category-overrides))
>
> instead:
>
> - Again, the user is still able to configure the display-sort-function
>   by configuring the individual completion table.

Does this mean that every individual completion table should have
a separate user option?

>   That's not true with display-buffer.  The only configuration
>   mechanism is display-buffer-alist.

Actually several user options already exist for display-buffer such as
display-comint-buffer-action and display-tex-shell-buffer-action.
They cover a whole category of display-buffer calls that display
all types of comint buffers, etc.  So these options correspond
to completion categories, not to individual completion tables.

> - Given that the user can still configure the display-sort-function, I
>   don't see any use case where the user should override it.  (A buggy
>   completion table that returns the wrong display-sort-function?  But
>   that should just be fixed.)

I don't understand how the user can configure the display-sort-function,
please elaborate.

> - display-buffer-alist is driven purely by buffer-match-p conditions, so
>   there's a linear sequence of overriding.  The display-sort-function
>   has two levels: the completion table and the completion category.
>   Since the table is more specific than the category, it should override
>   the category.

Agreed.  But this means only one thing that a user option
for an individual completion table should take precedence
over completion-category-overrides.

> - As a minor point, I, and many other Emacs users IME, find the
>   display-buffer configuration to be complex and hard to use, so I don't
>   think we should try to emulate it too much.

What is an alternative?  A myriad of individual options?

> - The "overrides" in "completion-category-overrides" is just a name.  It
>   doesn't mean that we have to make it override everything else.

Why not to do what the name suggests?

> Alternatively, could we just add support for configuring the individual
> table now, and add category-based configuration later?  We don't need to
> add everything all at once, and that will give us valuable user
> feedback.

I see no need to add individual options as all.  Every completion table
that significantly differs from other tables so that it needs a separate
display-sort-function, could provide a separate category.  For example,
there is a category 'buffer'.  If 'switch-to-buffer' needs another
display-sort-function it could provide a category 'buffer-for-switching'.