Re: Updating *Completions* as you type

[Juri Linkov]

>> 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.

> 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'.

>> 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 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.