bug#22407: Better support external completion tools

[Stefan Monnier]

>> I was thinking of applying (within Emacs) the regexp/predicate to a list
>> of candidate returned by the external tool.  Not passing it directly to
>> the external tool
> That would make it harder to use external tools that operate on large
> datasets. And since essentially, with this approach we're not delegating
> filtering to the external tool, it seems like it should work with the
> current completion-styles mechanism. No need to allow overriding
> completion-all-completions.

I guess you're right: it would only work in those cases where the
current system is already usable.  After all, all-completions already
has the completion-regexp-list at hand, if it wants to use it.

So for now, all we can do is to hope that the external tool can "honor"
the completion-styles somehow, but without providing any specific help
for that.

>>> As an aside, I wonder if the current completion styles, at least, could each
>>> be automatically implemented on top of the input-to-regexp functions,
>>> without loss in efficiency.
>> "input-to-regexp"?  Sorry, doesn't ring a bell.
> "a function which takes a user-input string and return a regexp".
> Could we use that not just as "description", but as definition for existing
> styles. And maybe keep the current mechanism for the trickier ones.

The current code already uses "turn input into a regexp, then use this
regexp to filter the worthy candidates".

We should add a `regexp' completion-style.  I never got around to do it,
but it shouldn't be very hard and it would probably provide the kinds of
function you're looking for.  Note that for the general "I just have
a regexp" case, implementing a good "try-completion" is hard.

And yes, partial-completion has additional complexity on top of that to
exploit boundaries so you can type C-x C-f ~/e/e/e TAB and have it
complete to ~/etc/emacs/emacs.el, but for the common boundary-free case
(or for completion-styles which don't want to do anything clever with
boundaries) it's not that hard.


        Stefan