emacs-devel
[Top][All Lists]
Advanced

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

Re: company-mode: Prevent unnecessary and unexpected calls to capf hooks


From: Stefan Monnier
Subject: Re: company-mode: Prevent unnecessary and unexpected calls to capf hooks
Date: Tue, 04 Dec 2018 11:01:05 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

[ Not sure where you got the "smonnier" in my email, probably a typo.  ]

> This started in https://github.com/company-mode/company-mode/pull/845
> and Dmitry suggested I bring it here for comments.

[ I actually just replied there a few minutes ago.  So here's a copy of
  what I said there.  ]

I think I see what João is talking about: I don't think describing it as
"the very first call" is quite right, and neither is the lexical
environment really relevant (the two calls to capf may simply return two
different function symbols, with no closures in sight), but indeed,
the :exit-function goes together with the completion-table. If you
insert a completion from the completion table, then call capf you might
very well receive a different completion table with a different
exit-function, so the exit function you should call after inserting
a completion is the one you got when you received the original
completion table, not the one you get when you re-call capf.

So the problem is that the company-backend API doesn't give us the
relevant info: when post-completion is invoked all we know is what has
just been inserted, but the completion data (table and exit-function)
which was used to choose this completion is not available to
company-capf. João's patch is a workaround which takes advantage of the
existence of the cache to try and recover the relevant completion data,
under the assumption that the cache has last been refreshed just before
performing the insertion, so it should happen to contain just the data
we need.

I don't know whether João's patch is the best solution, but at least
I can't think of a better one right now: we could try and de-insert the
text, call capf, and then re-insert the text instead, which would avoid
the reliance on the cache, but that sounds ugly; we could also call capf
from the position right before the insertion which is a bit less ugly
but may sometimes still return incorrect data.

This said, the comment should better explain the problem and make it
explicit that this is a workaround.


        Stefan




reply via email to

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