Re: Updating *Completions* as you type

[Juri Linkov]

>> This is what I believe they should do: we add a category,
>> and they support it as well.
>
> OK, I'm fine with that, but when we do that, I think the per-table
> option should override the per-category option.

I agree that the per-table option should override the per-category option,
but see no way to distinguish customized values from hard-coded ones
without trying to turn all hard-coded values into options.

display-buffer has a similar problem, but the difference is that
it's possible to identify a buffer by its name and use a regexp
to match buffer names.  Whereas for completing-read it's not easy
to identify a completion table.  A category matches a set of
completion tables, so maybe we need another identification
for individual tables?

> I'm OK with a category-based approach.  I just think we should reserve
> the *ability* to use table-specific options, by making a table-specific
> display-sort-function override the category-specific display-sort-function.

Probably introducing a new field to metadata could help to resolve ambiguities.

> Anyway, we're going around in circles a bit here.  How about this patch
> which only adds the new historical option to completions-sort?  I think
> we're in agreement on everything in this patch, and maybe installing it
> will get some user feedback which we can use when coming back to this
> later.

Thanks, everything looks nice, only a etc/NEWS announcement is missing.