Re: Separating completion candidates and filtering

[Stefan Monnier]

> AFAIU, completion backends such as Helm and Ivy essentially call the
> `minibuffer-completion-table' mainly to get the list of candidates, and
> then does the filtering on its own.

Indeed, this is a problem.  E.g. for completion-tables like those that
complete file names, that just can't work since the "complete" table is
virtually infinite and the completion-table doesn't know how to
enumerate this "complete" table, but only how to do "small steps".

> One possible solution to this is adding a new value option for `action'
> in `complete-with-action' that instructs `completion-table-with-context'
> to just return the table.

That means adding a new value `identity' for `action' to the API
implemented by *all* completion tables.  IOW a new method (if you look at
completion tables as objects that implement a particular interface).

> @@ -164,6 +164,7 @@ complete-with-action
>     ((functionp table) (funcall table string pred action))
>     ((eq (car-safe action) 'boundaries) nil)
>     ((eq action 'metadata) nil)
> +   ((eq action 'identity) table)
>     (t
>      (funcall
>       (cond

It's not sufficient because when you pass `identity' to
a completion-table, you don't know that this table was built with
complete-with-action, and since `identity' was not a known possible
value, the completion table may do arbitrary things in this case,
including returning something that can look like a "table" but isn't
what you expected.  So you need to do what we did with `boundaries' and
with `metadata', i.e. wrap the return value (e.g. with "(cons 'identity
table)") such that you can detect with a high probability that the
returned value is indeed what you expect.

Another issue is to define really what it is that you expect to receive
when you call a completion-table with argument `identity' (I strongly
suspect that answering this question will lead to changing its name, BTW).

BTW, another approach could be to write a function which takes
a completion-table and "folds it out".  I.e. call `all-completions` on
"" to get an initial list of candidates, then check whether those
candidates's boundaries are different from 0 and if so call
all-candidates on those values, etc...

So the first call to (all-completions "" table) might return ("a=" "b=") after
which you notice that (completion-boundaries "a=" table) doesn't return
0 so you call (all-completions "a=" table), and same thing for "b=",
so in the end the function will have constructed the ("a=foo" "a=bar"
"b=hello" "b=world") table.


        Stefan