Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I think I've also mentioned that selection can be hierarchical. I think
>> this too would be applicable to insert-char, considering how unicode
>> divided into groups and subgroups.
>
> I agree that hierarchical selection can be useful when browsing through
> a structure. However when doing a quick selection, I perceive it as
> slower. For example there is imenu, where you have to step through multiple
> layers of the hierarchy to reach the destination. A popular demand is for
> a flattened imenu which allows faster completion, see for example the
> package flimenu or counsel-imenu. But as soon as you flatten you certainly
> use the ability to browse the structure, so you have some point.

[ I like `completing-read`-based selection, so the below is written
  from that point of view, but I agree with Philip that it's important
  to design the API so that other UIs can also be used.  ]

For imenu, it makes sense to be able to say "v/foo" to select that
variable "foo", but also to just say "foo" when you don't want to bother
stating the category (because presumably there's only one "foo" anyway).

It would also make sense to complete unicode char names with extra
constraints like "s=foo bar" to get the chars whose name matches "bar"
and whose script matches "foo".

> I wonder how all these use cases could be unified under a common
> API. I would certainly not want to lose the current fast, flat selection
> mechanism via completion as offered by `completing-read'.

Maybe we could add methods to completion tables that return the set of
"characteristics" that can be used to filter, others that list the set
of possible values of those characteristics, etc...


        Stefan