From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: company-mode: Prevent unnecessary and unexpected calls to capf hooks Date: Tue, 04 Dec 2018 11:01:05 -0500 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1543939165 19862 195.159.176.226 (4 Dec 2018 15:59:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 4 Dec 2018 15:59:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 04 16:59:20 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUD6W-00052P-Nd for ged-emacs-devel@m.gmane.org; Tue, 04 Dec 2018 16:59:20 +0100 Original-Received: from localhost ([::1]:57734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUD8d-0008Vc-5k for ged-emacs-devel@m.gmane.org; Tue, 04 Dec 2018 11:01:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUD8W-0008VW-Je for emacs-devel@gnu.org; Tue, 04 Dec 2018 11:01:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUD8Q-00054k-Er for emacs-devel@gnu.org; Tue, 04 Dec 2018 11:01:22 -0500 Original-Received: from [195.159.176.226] (port=46686 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gUD8P-00052i-6k for emacs-devel@gnu.org; Tue, 04 Dec 2018 11:01:18 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1gUD6B-0004WB-Rq for emacs-devel@gnu.org; Tue, 04 Dec 2018 16:58:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:MogqeG6+CNK0FnpTQNWKqbdizTs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231614 Archived-At: [ 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