bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#16334: 24.3.50; company-capf eats the first char in IELM filename co


From: Dmitry Gutov
Subject: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions
Date: Fri, 10 Jan 2014 10:23:56 +0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Stefan Monnier <monnier@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]