[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22407: Better support external completion tools
From: |
Dmitry Gutov |
Subject: |
bug#22407: Better support external completion tools |
Date: |
Wed, 20 Jan 2016 04:13:15 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
On 01/19/2016 05:19 PM, Stefan Monnier wrote:
Note: checking (memq 'partial-completion completion-styles) is
fundamentally broken since the user may be using its own
`my-partial-completion' instead.
On the other hand, the external tool might simply have a set of matcher
styles you can ask it to use. Then memq could at least be helpful.
So maybe to avoid this problem and
make it easier for those completion-tables to honor `completion-styles',
we could extend `completion-styles-alist' so that each style can provide
some "description" of the kinds of candidates it would accept. Not sure
what that "description" could look like, tho. Maybe a function which
takes a user-input string and return a regexp, or maybe a simple
predicate taking a user input string and a candidate and returns whether
to keep it or not.
I don't see how the predicate could be used at all. As for regexp, we
should make a survey of the existing external completion tools, and see
how many of them take a regexp for this purpose.
There's also the issue of Emacs/basic/extended regexp syntax.
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. Is the completion boundaries,
used by partial-completion, the main problem?
Probably neither would work well enough, tho
(e.g. if the completion-table includes candidates that fix typos in the
user-input string).
Neither will be perfect, that's for sure. But maybe we don't have to
worry about that too much: IME, users are mostly interested in the
distinction between prefix and fuzzy completion, with many preferring
the latter.
The next question becomes how to sort (or not) the returned list: fuzzy
matching returns lots of matches, so they're usually sorted at the same
time. If completion-at-point re-sorts them alphabetically, that
advantage will be lost. Using #'identity as display-sort-function should
work, though.