From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#11906: 24.1; completion-at-point failures Date: Wed, 22 May 2013 03:39:13 +0400 Message-ID: <87li776gym.fsf@yandex.ru> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1369179632 29042 80.91.229.3 (21 May 2013 23:40:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 May 2013 23:40:32 +0000 (UTC) Cc: Leo Liu , 11906@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed May 22 01:40:31 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UewAQ-0008Ek-OK for geb-bug-gnu-emacs@m.gmane.org; Wed, 22 May 2013 01:40:30 +0200 Original-Received: from localhost ([::1]:51988 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UewAQ-0001pG-7F for geb-bug-gnu-emacs@m.gmane.org; Tue, 21 May 2013 19:40:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54763) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UewAK-0001pA-AI for bug-gnu-emacs@gnu.org; Tue, 21 May 2013 19:40:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UewAH-0008Bb-O0 for bug-gnu-emacs@gnu.org; Tue, 21 May 2013 19:40:24 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UewAH-0008BW-Jm for bug-gnu-emacs@gnu.org; Tue, 21 May 2013 19:40:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UewAw-0006v5-91 for bug-gnu-emacs@gnu.org; Tue, 21 May 2013 19:41:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 May 2013 23:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11906 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136917960726497 (code B ref 11906); Tue, 21 May 2013 23:41:02 +0000 Original-Received: (at 11906) by debbugs.gnu.org; 21 May 2013 23:40:07 +0000 Original-Received: from localhost ([127.0.0.1]:55309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UewA3-0006tJ-AN for submit@debbugs.gnu.org; Tue, 21 May 2013 19:40:07 -0400 Original-Received: from mail-la0-f52.google.com ([209.85.215.52]:48001) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uew9z-0006sY-6Z for 11906@debbugs.gnu.org; Tue, 21 May 2013 19:40:04 -0400 Original-Received: by mail-la0-f52.google.com with SMTP id fo13so1322856lab.25 for <11906@debbugs.gnu.org>; Tue, 21 May 2013 16:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:x-antivirus:x-antivirus-status; bh=fZkbdnXhV2dBOZ9Axj7iCe4u9YRa6FsC/xkxx3n4ob0=; b=FCOICqi58BmF9n+b3UCl/QucEcjE9t/HkHyRg9hhui1ikmmCE8kptbJ5yFRZPgLpBu XD65yeTJsmFaJ/x7jbxdK+iGa+QWZTEGLfpVtYUPCDwk+Pnt9tw9h4/I3w8MLX//fePV 9iAM3wFJuWLAPbb4+C7rgpz9NSb7577IsFRtw61oCVFrU+n8UA5a1VCy+tsQhgxX7TiS oMR2j1fEezZbo4SI4VfSudrpqhtAbZ9CuQkj4nA/eTAxAbmtDabVeOo3hdgs9XD4RpkW LNHov/DVM9A9OW81HQNJH1FzbtG9LTz+4jugkxFclqrfbATiWQsO7TGdZ/+Nc7Fk9xY7 dgwQ== X-Received: by 10.152.8.231 with SMTP id u7mr2595845laa.27.1369179555603; Tue, 21 May 2013 16:39:15 -0700 (PDT) Original-Received: from SOL ([178.252.98.87]) by mx.google.com with ESMTPSA id t4sm1953513lbe.7.2013.05.21.16.39.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 May 2013 16:39:14 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 10 May 2013 23:40:39 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) X-Antivirus: avast! (VPS 130521-1, 21.05.2013), Outbound message X-Antivirus-Status: Clean X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:74438 Archived-At: I've seen this very same problem when writing and using a completion-at-point function for Ruby, via external live process, so it's also comparably slow. Stefan Monnier writes: >>> The difference between 2 and 3 calls shouldn't be sufficiently large to >>> go from "acceptable" to "terrible delay". >> It is a difference between 1 and 3 calls because a user can also run >> octave in terminal and find that how responsive it actually is. > > But the generic completion code can't easily go down to a single call in > the general case. Why not? I have a function, called `robe-complete-thing', which is used as a "dynamic completion table" via `completion-table-dynamic'. Whenever I press `C-M-i' in a relevant buffer, `robe-complete-thing' gets called 2 times if the symbol is "complete, but not unique", or 3 times if the symbol is not complete, and the *Completions* buffer should be displayed. Whatever code drives this logic, I imagine all places that access the dynamic completion table do that is specific order. And since they all look up completions for the same term, can't the first of them save the lookup result, so that all other places will use the saved value? All that in the scope of one `complete-symbol' call. >> I think if completion-at-point can work well when there is a 2-second >> cost in a completion-at-point function, it can provide an excellent >> experience. > > Obviously it can, via caching. Most completion tables which incur > a significant computation code should use caching, but we can't use > caching unconditionally, because it's hard to come up with a general > conditions under which the cache can be reused or needs to be flushed. The one most visible problem case is when the dynamic completion table is called several times at once for the same term. Caching is a possible solution, but it doesn't seem to me that caching anything more than the last request-response pair would be too useful. > As mentioned, we could try and provide a generic completion-table cache > so as to make it easier to write completion tables that have > a significant computation cost. Patches welcome. So, suppose we do provide a caching function. Would it cache more than just one pair? If not, it won't be too hard to do in `completion-table-dynamic', or in an additional function that would wrap FUN and then pass it to `completion-table-dynamic'.