emacs-devel
[Top][All Lists]
Advanced

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

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


From: João Távora
Subject: company-mode: Prevent unnecessary and unexpected calls to capf hooks
Date: Tue, 04 Dec 2018 15:30:51 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt)

Hi there,

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

Here's a summary:

In eglot.el I am putting a function, eglot-completion-at-point, into the
special hook completion-at-point-functions.  When called, that function
returns a list according to the protocol and in that list are, also
according to the protocol established by completion-extra-properties,
values for :exit-function and :annotation-function.  Instead of passing
named functions as values, I pass lambdas.  These lambdas capture the
lexical environment of eglot-completion-at-point, attempting to save
useful stuff like how the buffer looked just before the completion
attempt.

Now, when using Emacs's own capf frontend, completion-at-point, the
ensuing mechanism guarantees that the version of those lambdas being
called is always the version returned by **the first call to
eglot-completion-at-point**, even in the case of :exit-function, which
is only called after the completion is performed.  At that point in
time, by definition, the buffer state has changed (and this is why it's
very useful to capture it in a closure).

Dmitry and I differ on the actual reason behind this characteristic of
Emacs's completion-at-point: Dmitry thinks it is accidental (as in: it's
the way it works now, could change in the future). I think this should
be viewed as a formal guarantee, even if is yet unwritten (I think).

Accidental or formal, Company-mode breaks this, because its caching
conditions for an internal function that it uses to get to CAPF data
unconditonally break just before calling :exit-function.  I proposed a
fix to Dmitry that would bring back this guarantee for all intents and
purposes, but Dmitry is hesitant.

Can someone shed some light into this, so either Dmitry can fix it or I
can give up lexical captures in my CAPF :exit-function?

Thanks,
João






reply via email to

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