Juri Linkov writes: >>>>> 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. OK, I'm fine with that, but when we do that, I think the per-table option should override the per-category option. >>>>> 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. Yes, but we don't have to do that, 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. 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.