From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 16334@debbugs.gnu.org
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 [thread overview]
Message-ID: <87vbxs73sz.fsf@yandex.ru> (raw)
In-Reply-To: <jwv8uupf95g.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Thu, 09 Jan 2014 11:00:10 -0500")
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.
next prev parent reply other threads:[~2014-01-10 6:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 23:20 bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Dmitry Gutov
2014-01-04 5:00 ` Stefan Monnier
2014-01-05 2:20 ` Dmitry Gutov
2014-01-05 3:17 ` Dmitry Gutov
2014-01-05 4:53 ` Stefan Monnier
2014-01-06 5:33 ` Dmitry Gutov
2014-01-06 15:23 ` Stefan Monnier
2014-01-07 2:52 ` Dmitry Gutov
2014-01-08 3:33 ` Stefan Monnier
2014-01-09 6:21 ` Dmitry Gutov
2014-01-09 16:00 ` Stefan Monnier
2014-01-10 6:23 ` Dmitry Gutov [this message]
2014-01-10 14:58 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vbxs73sz.fsf@yandex.ru \
--to=dgutov@yandex.ru \
--cc=16334@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.