GNU bug report logs - #16334
24.3.50; company-capf eats the first char in IELM filename completions

Previous Next

Package: emacs;

Reported by: Dmitry Gutov <dgutov <at> yandex.ru>

Date: Fri, 3 Jan 2014 23:21:02 UTC

Severity: normal

Found in version 24.3.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 16334 <at> debbugs.gnu.org
Subject: Re: bug#16334: 24.3.50;
 company-capf eats the first char in IELM filename completions
Date: Fri, 10 Jan 2014 10:23:56 +0400
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> This is a limitation inherited from the "original" completion
> infrastructure.  We could easily introduce a replacement for
> completion-regexp-list which specifies a "pattern" (in a format to be
> defined).

A list of segments would a natural choice, but I was thinking about a
more radical change: allowing backends to handle the completion styles.
At the moment, `completion--nth-completion' tries all allowed styles,
and returns the candidates for the first style that succeeds.

Firstly, one might prefer to see candidates for several styles, ranked
and merged, like described here:
https://github.com/company-mode/company-mode/issues/45#issuecomment-31564029

We could tell the backends about accepted styles (maybe it would be in
their metadata if they can handle styles on their own), and then trust
them to return appropriate results.

The main problem with this approach would be to make sure frontends can
handle not knowing which style was used to find a given completion
candidate. Or maybe require backends to hand over that information.

>> And a service's implementation of different completion styles could be just
>> as fast, if not faster.
>
> Of course, it's only interesting if it's faster, otherwise, why bother?

Even if the filtering speed is about the same, speedup can come from
less time spent serializing/deserializing the full candidates list.

And, if we want to return results from different styles together, from
making less network calls, and from not forcing the backend to do any
preprocessing required by completion code multiple times.




This bug report was last modified 11 years and 138 days ago.

Previous Next


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