unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).