Juri Linkov <juri@linkov.net> writes:
>>> 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.

Right.  I guess my position is that there's not that many hard-coded
display-sort-functions (only 5 in core Emacs), so turning them all to
options is fine.

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

True, that would help.  Maybe the function symbol for the completion
table?  Tables are usually lambdas today, but maybe we could make it
easy to use a defun'd function instead, which would be very good for
comprehensibility in general IMO.

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

Added.