Separating completion candidates and filtering

Separating completion candidates and filtering

[Alex]

[-- Attachment #1: Type: text/plain, Size: 1664 bytes --]

Hello everyone,

I'd like to know if there's currently a way for a `completing-read'
procedure to instruct to a `minibuffer-completion-table' procedure that
it should not do any filtering via, e.g.,
`completion-table-with-context'.

Here is my specific use case: For some reason, I'm looking at making a
nicer interface for completing "key=value" pairs in Emacs, which uses
AUCTeX's `multi-prompt-key-value'[1]. This nicer interface is mainly for
certain 3rd-party completion backends, such as Helm[2] and Ivy[3].

I got the system working more or less how I'd like it (I plan on posting
it in the near future), but one issue I'm having is that the procedure
`multi-prompt-key-value-collection-fn' uses
`completion-table-with-context', which filters the candidates using
simple prefix completion (when used with `all-completions').

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. As it stands, candidates are being
filtered by `m-p-k-v-c-f' and by Helm/Ivy's own filtering mechanisms,
leading to suboptimal (though not wrong) results.

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. I've included a diff that does this[4] below.

I'm not very familiar with the contents of minibuffer.el, so I'm sorry
if I'm missing something obvious.

Footnotes: 
[1]  https://git.savannah.gnu.org/cgit/auctex.git/tree/multi-prompt.el#n188

[2]  https://github.com/emacs-helm/helm

[3]  https://github.com/abo-abo/swiper

[4]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: complete-with-action.diff --]
[-- Type: text/x-diff, Size: 383 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index e5b1029c01..105e7f36e5 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -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

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