Re: Updating *Completions* as you type

[Spencer Baugh <sbaugh@janestreet.com>]

Juri Linkov <juri@linkov.net> writes:
>> Finally got to it, I've added that in this patch (which combines both
>> the read-buffer-sort and completions-sort changes).
>
> Thanks, a quick test shows that everything works nicely.
>
>> +      Lisp_Object res = list2 (Fcons (Qcategory, Qbuffer),
>> +			       Fcons (Qcycle_sort_function, Qidentity));
>> +      if (EQ (Vread_buffer_sort, Qbuffer_list))
>> +	res = Fcons (Fcons (Qdisplay_sort_function, Qidentity), res);
>> +      else if (FUNCTIONP (Vread_buffer_sort))
>> +	res = Fcons (Fcons (Qdisplay_sort_function, Vread_buffer_sort), res);
>> +      return Fcons (Qmetadata, res);
>
> I still have doubts about adding separate sorting options for
> every completion category.

Not just every completion category, every completion table.

What are your doubts?  I don't think it ends up being too many options
in practice.  The discoverability is worse than a centralized solution,
but it also keeps configuration localized to the individual component,
which is nice and makes it easier to group buffer/file/etc settings
together in configuration and the Customize interface.

One important feature of separate sorting options is that they support
sorting details which are specific to the individual completion table.
For buffers, for example, sorting by the buffer-list can be done by just
setting display-sort-function to identity, but we probably shouldn't
expose that fact to the user.  (We could expose a generic "sort by
defaults" but that would be less efficient.)

The sorting style might even require the sorting option to actually
change the completion table's behavior.  File name completion could be
sorted by mtime, for example, by having the completion table include
mtime as a text property when read-file-name-sort=mtime, and then
setting display-sort-function to something which reads that property.  I
think that can only work if we have separate sorting options.

> What do you think about adding customization of display-sort-function
> to the existing option completion-category-overrides?
>
> This would allow users such customization for 'C-x b' and 'C-x p p'
> to sort buffers and projects by history:
>
>   (setopt completion-category-overrides
>     '((buffer (display-sort-function . minibuffer-sort-by-history))
>       (project-file (display-sort-function . minibuffer-sort-by-history))
>
> And default values could be specified in completion-category-defaults.

Hm, this could be okay.  It does sacrifice the extra level of
customization possible with separate sorting options that I just
described.

I think the default values would be part of the completion table itself;
a completion table can just set display-sort-function itself, it doesn't
need completion-category-defaults to do that.

Indeed, currently completion-category-overrides and defaults are used
only to configure things which can't be directly set by the completion
table.  That's my understanding of the purpose of completion categories:
the completion table returns a category symbol as a somewhat roundabout
way to configure completion-styles and completion-cycle-threshold to
values which are specific to the table.

But the completion table is already able to set display-sort-function on
its own.  So it's novel to also have completion-category-overrides able
to do that.

Maybe we should decide what things are supposed to be configured by
category and what things are supposed to be configured by the table
itself.  Because in theory we could allow setting completion-styles and
completion-cycle-threshold with completion table metadata, and I'm not
sure why we didn't do it that way - it could even be nice to have a
completion style which is specific to an individual completion table.