GNU bug report logs - #22407
Better support external completion tools

Previous Next

Full log

Message #8 received at 22407 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, 22407 <at> debbugs.gnu.org
Subject: Re: bug#22407: Better support external completion tools
Date: Wed, 20 Jan 2016 04:13:15 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.