From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: monnier@iro.umontreal.ca, bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jul 2012 06:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 11906 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 11906@debbugs.gnu.org Cc: Stefan Monnier X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Stefan Monnier Received: via spool by submit@debbugs.gnu.org id=B.134198638618782 (code B ref -1); Wed, 11 Jul 2012 06:00:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 Jul 2012 05:59:46 +0000 Received: from localhost ([127.0.0.1]:32926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sopxh-0004st-M1 for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:59:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54463) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sopxf-0004sl-UK for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:59:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SopsP-0001SH-QN for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:54:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsP-0001SC-KL for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:54:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsN-0003Fo-Uf for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SopsM-0001Rt-07 for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:15 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:47404) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsL-0001Rc-NU for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:13 -0400 Received: by pbbrp2 with SMTP id rp2so1700654pbb.0 for ; Tue, 10 Jul 2012 22:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:x-debbugs-cc:date:message-id:mime-version :content-type; bh=o2BhljlCH1AU0Z0fodu/Rj3NCxcbbMy7QYpF2fs4+mM=; b=QTpEAcBkRPpZ2bkVO9CO8fS1C4TXCd6Xk3yF4la0lJ3hKKbXAG5amEbm2D0RKEDLH9 guotaEOTWzXDGXp7sdAB0PHjb45AcBPlHX12BT7lPlaQZiVDNb3686pzRdohoYgoC13L 5NTM8rkX/Eo1rLwoh0IYd8k1iz+4KOS+E6FIx8eZWF9zrZSJNPg+U7mXi/LuDdZOLy4m bGfzLq55+n0mXFF/zltGSG4PqcRRoZm/9Nnx+6YC8SyJtsAUCI7EIEgJctg0Rx2u4mPn 8wpY22rDNZHeupfffa0x+wUs2V9sfniz88wk3h2ulJs6TuwGz+vatZLbFtN1EDapQ/94 Ibyw== Received: by 10.68.223.34 with SMTP id qr2mr75204456pbc.10.1341986050488; Tue, 10 Jul 2012 22:54:10 -0700 (PDT) Received: from localhost ([119.255.41.67]) by mx.google.com with ESMTPS id ms1sm1023543pbb.63.2012.07.10.22.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 22:54:09 -0700 (PDT) From: Leo Date: Wed, 11 Jul 2012 13:54:00 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Hello Stefan, Despite these critical points, I have witnessed great improvement over completions in earlier versions of Emacs. So thanks. Assume three candidates (ObjC selectors) for completion and completion-cycle-threshold is 5: 1. stringWithContentsOfFile: 2. stringWithContentsOfFile:encoding:error: 3. stringWithContentsOfFile:usedEncoding:error: After cycling a few times, I see: [NSString stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$ i.e. succeeding completion failed to remove previous one before inserting its own, it is, in this case, due to : in the completions. But the problem is general, completion-at-point can be tripped over by chars in the completion candidates. I can imagine it fails too if completion contains spaces. I dug a bit and realised that completion-at-point depended too much on members in completion-at-point-functions. Those functions are called multiple times for each trigger of completion. So it can be extremely slow when the calculation is slow. For example, preparing the completion table in ObjC could take a few seconds for libclang to analyse the source and turn the output into something suitable for consumption in Emacs. It seems completion-at-point should be able to do its entire work after obtaining once the data from those functions. This would free users of completion-at-point-functions from worrying about caching. completion-at-point also invokes those functions in order to decide when to exit. This causes problems illustrated at the beginning of this report and, for example, I have also experienced delay in inserting space, dot, etc following a completion. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jul 2012 14:07: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: To: Leo Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.134210199315319 (code B ref 11906); Thu, 12 Jul 2012 14:07:02 +0000 Received: (at 11906) by debbugs.gnu.org; 12 Jul 2012 14:06:33 +0000 Received: from localhost ([127.0.0.1]:36010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SpK2K-0003z1-Vy for submit@debbugs.gnu.org; Thu, 12 Jul 2012 10:06:33 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37744) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SpK2J-0003yv-BB for 11906@debbugs.gnu.org; Thu, 12 Jul 2012 10:06:32 -0400 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q6CE0vnV007673; Thu, 12 Jul 2012 10:00:57 -0400 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 59CB9AE3BA; Thu, 12 Jul 2012 10:00:55 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Thu, 12 Jul 2012 10:00:55 -0400 In-Reply-To: (Leo's message of "Wed, 11 Jul 2012 13:54:00 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4276=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4276> : streams <783344> : uri <1163404> X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) > Assume three candidates (ObjC selectors) for completion and > completion-cycle-threshold is 5: > 1. stringWithContentsOfFile: > 2. stringWithContentsOfFile:encoding:error: > 3. stringWithContentsOfFile:usedEncoding:error: > After cycling a few times, I see: > [NSString > stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$ The behavior will surely depend on exactly how you do the above. So, could you give more details, such as which modes you're using and which keys you pressed? > Emacs. It seems completion-at-point should be able to do its entire work > after obtaining once the data from those functions. This would free > users of completion-at-point-functions from worrying about caching. Sometimes, you can't get the whole data at once (e.g. completion of a file-name would have to return all the files in all directories if it had to be done "a once"). So, this is not an option. But we could provide a standard completion-table constructor that provides caching. > completion-at-point also invokes those functions in order to decide when > to exit. This causes problems illustrated at the beginning of this > report and, for example, I have also experienced delay in inserting > space, dot, etc following a completion. Can you explain how "this causes problems"? What makes you think it's related? Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 May 2013 06:39:04 +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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136816792618102 (code B ref 11906); Fri, 10 May 2013 06:39:04 +0000 Received: (at 11906) by debbugs.gnu.org; 10 May 2013 06:38:46 +0000 Received: from localhost ([127.0.0.1]:35281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uagya-0004ht-8e for submit@debbugs.gnu.org; Fri, 10 May 2013 02:38:46 -0400 Received: from mail-pa0-f51.google.com ([209.85.220.51]:45534) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UagyN-0004hM-Ie for 11906@debbugs.gnu.org; Fri, 10 May 2013 02:38:38 -0400 Received: by mail-pa0-f51.google.com with SMTP id ld10so2686820pab.10 for <11906@debbugs.gnu.org>; Thu, 09 May 2013 23:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=cmPq63013X/RuNYWizGRA/BB2xqTIjXnjRNjoxfztvk=; b=sMpcbda7Uvef2PlCM1iZuCNPnniyUN3NMinraLneJzfNLTXygW1bd1Qh4E6sQaRQYY BDMxZ2BLWS8soDW3axD7HZaVmftCxSd4jpRYFvxWeSlmR51fE8/ackIVeenune6vH3nu bQ9ErnCSmUxEFFEVegKMzzJ/SQy4KrVuudFktBP3s1naYn6nY6vkupNm1oW+p9HepFZT tKTETWpKIFq3c7Z2oY2sKdAALBWXt7pW9Nl9VWnl2AXXz+q2oRWKKHYI7t5xlmtnvMZJ Pi+ofuVMHTVWlJda5Yu9dhEdFUojYtp8nKW6KHjs7M4k6WmydcQ/MYjprRGx2uoSgEI+ nxbA== X-Received: by 10.66.160.104 with SMTP id xj8mr16365562pab.3.1368167902285; Thu, 09 May 2013 23:38:22 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id qb1sm1439958pbb.33.2013.05.09.23.38.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 09 May 2013 23:38:21 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAG1BMVEUAAAA9Cgm3Hx1WWFWA gn+WmJWsrqv4+vcCAwCRl2MkAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAAJcEhZcwAAAYoA AAGKATOXMFgAAAAHdElNRQfXAQwDNR+ZJmElAAABIklEQVQoz22SPW+DQAyGWUq65qasd9PNUSX4 AZHK2C1rJy5jpDS4IwRVup9dn7GNafpKIPPgzztXFSujqq1eM2n8h22oMkvxI/i9C97kRfMRUN55 dS3BrsAwBXUtMLAO4lryh8kTjOxKpQNniNxAgZOEe4bZwsDTFhKdqZRLNII4OQNHhEuq/RMkm6Cj TnnEA/fk0BorcYn5qA3oaeAxbaBOLrX+9G48NZ2Fzc2tzDM8Q+tMypEOqYHh8mAWaaK3U/cDMOT5 aMZMABgPXc7zPMs1A8DXO756GFJ/4fMEq47hTsAdn5avoxZ4ywl0c2w4Flu2Ybeyb3S+EqxX2DYA H8veJGEDTnHnrXvRaPyt+2kSfK6rfBZ2tUtfP/mR+pR6sX8BUZ/cDV7tvkoAAAAASUVORK5CYII= Date: Fri, 10 May 2013 14:38:09 +0800 In-Reply-To: (Stefan Monnier's message of "Thu, 12 Jul 2012 10:00:55 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2012-07-12 22:00 +0800, Stefan Monnier wrote: >> Emacs. It seems completion-at-point should be able to do its entire work >> after obtaining once the data from those functions. This would free >> users of completion-at-point-functions from worrying about caching. > > Sometimes, you can't get the whole data at once (e.g. completion of > a file-name would have to return all the files in all directories if it > had to be done "a once"). > > So, this is not an option. But we could provide a standard > completion-table constructor that provides caching. > >> completion-at-point also invokes those functions in order to decide when >> to exit. This causes problems illustrated at the beginning of this >> report and, for example, I have also experienced delay in inserting >> space, dot, etc following a completion. > > Can you explain how "this causes problems"? What makes you think > it's related? OK, I just hit another performance issue with this repetitive invoking of completion functions by completion-at-point. To see this issue: 1. emacs -q (choose an emacs that doesn't have the fix in revision 112539) 2. M-x run-octave 3. Type 'uint ' 4. Type 'history 10' You should see: 1040 completion_matches ("uint"); 1041 completion_matches ("uint"); 1042 completion_matches ("uint"); 1043 history 5 So basically computation for the matches against 'uint' has been done three times. Now when the computation is expensive (such as against the empty string "") one should observe a terrible delay. I have to work around this issue in octave by revision 112539. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 May 2013 20:37: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136821818929201 (code B ref 11906); Fri, 10 May 2013 20:37:02 +0000 Received: (at 11906) by debbugs.gnu.org; 10 May 2013 20:36:29 +0000 Received: from localhost ([127.0.0.1]:35930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uau3E-0007ao-0u for submit@debbugs.gnu.org; Fri, 10 May 2013 16:36:28 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]:37088) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uau37-0007aZ-JG for 11906@debbugs.gnu.org; Fri, 10 May 2013 16:36:22 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id r4AKa586011869; Fri, 10 May 2013 16:36:05 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 3A494B4161; Fri, 10 May 2013 16:36:05 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Fri, 10 May 2013 16:36:05 -0400 In-Reply-To: (Leo Liu's message of "Fri, 10 May 2013 14:38:09 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4575=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4575> : streams <958174> : uri <1416861> X-Spam-Score: -4.8 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.8 (----) >>> completion-at-point also invokes those functions in order to decide when >>> to exit. This causes problems illustrated at the beginning of this >>> report and, for example, I have also experienced delay in inserting >>> space, dot, etc following a completion. >> Can you explain how "this causes problems"? What makes you think >> it's related? > OK, I just hit another performance issue with this repetitive invoking > of completion functions by completion-at-point. To see this issue: > 1. emacs -q (choose an emacs that doesn't have the fix in revision 112539) > 2. M-x run-octave > 3. Type 'uint ' > 4. Type 'history 10' I don't understand this recipe: where should I type "history 10"? right there after the "uint" text? > You should see: > 1040 completion_matches ("uint"); > 1041 completion_matches ("uint"); > 1042 completion_matches ("uint"); > 1043 history 5 Where should I see it? Ah, OK. so I should type RET before "history 10", so history shows me the last commands run by octave. > So basically computation for the matches against 'uint' has been done > three times. Fine, yes. There can be various reasons why the completion table is run several times. In the present case, 2 is the minimum: once to try and complete "uint" (which just returns "uint") and once to get the completion candidates. Why there's a third call? I couldn't tell you off the top of my head. Maybe it's an inefficiency somewhere. > Now when the computation is expensive (such as against the > empty string "") one should observe a terrible delay. The difference between 2 and 3 calls shouldn't be sufficiently large to go from "acceptable" to "terrible delay". > I have to work around this issue in octave by revision 112539. Using a cache is a good idea: when there's no completion, the completion code may call the completion-table many more times than just 3 times (typically, it will call it at least once per completion-style). Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 01:52:01 +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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136823707619408 (code B ref 11906); Sat, 11 May 2013 01:52:01 +0000 Received: (at 11906) by debbugs.gnu.org; 11 May 2013 01:51:16 +0000 Received: from localhost ([127.0.0.1]:36045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uayxs-00052k-54 for submit@debbugs.gnu.org; Fri, 10 May 2013 21:51:16 -0400 Received: from mail-pd0-f180.google.com ([209.85.192.180]:52479) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uayxk-000522-R0 for 11906@debbugs.gnu.org; Fri, 10 May 2013 21:51:10 -0400 Received: by mail-pd0-f180.google.com with SMTP id t10so3132340pdi.25 for <11906@debbugs.gnu.org>; Fri, 10 May 2013 18:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=+UBLl3usT0LPJnHmnzDCBcCAVLcCKFuNHL9u+rYtlSQ=; b=v3IDffmsm+SJJ4LNH/2u7EeAUdnlTq9HaXcqVNBnFtQu+Q1DssypdNyFUrXNxDRBob 4eQVjyFMND9bsItC7be6fxEhEftvPyVjsHydjmrvPUtANUXUCFXPl4OeCkKVzM5OQLyb u6duKqFKlP1E1E+7F/g5+mPFOwdU546oUoHti87CV0pWRgOLo3tNbPG4hK/FwGzD1zDN 2BuAiC/WSQtT+cjAnWWlphQS/4DS11C8Xh4ycQ/AnrrTVwwjkH7a1Gg0jgETZqwCPnXY ODi2bZpvI/QxDR7c8ypvVBZ5UhPiWd/DF0/4LoPE2gCfbd0Sa0FU0igG6BOgzrSNS+gZ gJIg== X-Received: by 10.66.144.233 with SMTP id sp9mr20000663pab.178.1368237050945; Fri, 10 May 2013 18:50:50 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id pa2sm4921043pac.9.2013.05.10.18.50.48 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 10 May 2013 18:50:50 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoAgMAAADxkFD+AAAADFBMVEUvT09qWs3/pQD///+J kUVcAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMLOd3veKQA AACuSURBVBjTldE9CgIxEAXgB+lEyFUC2wo5ikdZ8DSypxhMY7H9VuIVwlqkGRgnm59VsHGafIQ3 CZlAtmKIRaHETgYa12lqvEsPYKf8wXHsPGfqPaUM0g9aJPKFXkmNQmSDqwzz4Fpgpz+6WAPY2z5o uPJJpu0uypcl4nyCibMLQ8lCiVjayLoQvw5LsVKQuHPRR958HZbOcVsKeepcLxpByjycGvnKmY+c MBvrtyjfe0vmuLvdq/kAAAAASUVORK5CYII= Date: Sat, 11 May 2013 09:50:43 +0800 In-Reply-To: (Stefan Monnier's message of "Fri, 10 May 2013 16:36:05 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 2013-05-11 04:36 +0800, Stefan Monnier wrote: > > > Ah, OK. > so I should type RET before "history 10", so history shows me the last > commands run by octave. Sorry, I wasn't clear. > 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. I noticed this long delay when completing empty strings (octave-completion-at-point used to allow empty strings). Emacs will be busy for a few seconds (something like 3 ~ 5 seconds in my laptop). Given how often I use the TAB key, it was terrible experience. > Using a cache is a good idea: when there's no completion, the completion > code may call the completion-table many more times than just 3 times > (typically, it will call it at least once per completion-style). I just want to point out these problems in the completion-at-point machinery. 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. > Stefan Thanks, Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 03: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136824365920614 (code B ref 11906); Sat, 11 May 2013 03:41:02 +0000 Received: (at 11906) by debbugs.gnu.org; 11 May 2013 03:40:59 +0000 Received: from localhost ([127.0.0.1]:36085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub0g4-0005M6-Js for submit@debbugs.gnu.org; Fri, 10 May 2013 23:40:58 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:54389) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub0g2-0005Lk-BX for 11906@debbugs.gnu.org; Fri, 10 May 2013 23:40:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IPAS-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="11783727" Received: from 184-175-6-252.dsl.teksavvy.com (HELO pastel.home) ([184.175.6.252]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 May 2013 23:40:35 -0400 Received: by pastel.home (Postfix, from userid 20848) id 6A49867A3A; Fri, 10 May 2013 23:40:39 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Fri, 10 May 2013 23:40:39 -0400 In-Reply-To: (Leo Liu's message of "Sat, 11 May 2013 09:50:43 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.5 (/) >> 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. > 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. 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. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 04:49: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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13682476955783 (code B ref 11906); Sat, 11 May 2013 04:49:02 +0000 Received: (at 11906) by debbugs.gnu.org; 11 May 2013 04:48:15 +0000 Received: from localhost ([127.0.0.1]:36111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub1jD-0001VD-Ep for submit@debbugs.gnu.org; Sat, 11 May 2013 00:48:15 -0400 Received: from mail-pa0-f46.google.com ([209.85.220.46]:61522) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ub1j9-0001Uy-IW for 11906@debbugs.gnu.org; Sat, 11 May 2013 00:48:12 -0400 Received: by mail-pa0-f46.google.com with SMTP id fa10so3388167pad.19 for <11906@debbugs.gnu.org>; Fri, 10 May 2013 21:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=8y3+65jDUknMIU0lAo+c+OoLJ0RkuF9PA/3hPDC7kwY=; b=ESAB1B4eBuiyZn8Kaj6+c/mxvCogzD37iN8+VRx5+N2DqJQdC0WfAW0dxXAmFTFi+1 LefHGUtYl9DqCXwGtj0iKVo+L2tJ4ZJ3YTR3zFTCOdCAYIEdVTwG1ZCyTKGuOVf/RuAO dmYYzOfVoWudi7cQ3MS3TblmfmpqUVCBNqvg1rcNn2w0KfJztKG2BsEyG0D0P04KMDlV hIOnqjwcqu9O9w8tlKwWZ6ERpBRr6HDUtzqw0HhBQVjIZzNAM/clvaTpIvqv6EYJFYsv /UIu5cweqErJqv1B46dNKxhU4m4U2HRJLRp6QqQmYvr216oZ3JB7zv08Wc6BpX8bl5fC Is2A== X-Received: by 10.68.90.197 with SMTP id by5mr19984936pbb.196.1368247677031; Fri, 10 May 2013 21:47:57 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id t1sm5441846pab.12.2013.05.10.21.47.52 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 10 May 2013 21:47:56 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUKDAg1NjRWV1V9fnyg op/DxcLk5uP8/voi63ReAAAACXBIWXMAAAWJAAAFiQFtaJ36AAAAB3RJTUUH1goZAgAz00bgXgAA AeVJREFUKM9lk0Fz2jAQhQXJD3CCO70CmcC1YMtcWyTZ14Bl69xats4N9r6/3zWQBlodNKNPu/s0 b1cCQFuZGpfVVh3vAvBJolIXRkapSuoRUtIdFyo1Y5xSdlAj7OtvD1XnXxmWRi+eWgcxyCed1lVV B1CrKyujMoi+eLA5kU1SsjoHlW+nQjTtFxk4MXgrOxvIqzoTZR8XgPaLl419zgsMaSGFPiUOZCIh thsx5Xy9NsK8Kwf/JoQgMxcVJ301HKkcSWaT0O7FY056J4U9xcYfnmVXG4801lW6lqwu2nKFZoHC HuzvaTVndZ+LaRQgZdthXw1cpynEkLEwyFHXk/aIxNQ6QeooJuzPMB+wn+D7JJNsiCcVA13/A3h/ xE9J+WidpAwoYNmRFwyvSRhNVtsdaAewzZZP5uw82QL9+tyNfocyP0McAzICUr5Mk9RdIjWasUNx aIIt6NK4ZtXIMdfMQt3nuMAyWbLI4DqZ4xPq/ag8jPond4XU/cLuOgw6XCFX/YCUfcDAMMH58fD4 G9kDchwfqVefkBwup2uZM+Q4WhJt5jN3AxXCsaS2yXEDuWgS8VOzW0gFjhEPmLyFMKBFaLb1HRwc DiaKwx0EeTMRYnYPQRW3PP4HApvlMv0PttX5v/D6Aws3IOSEwzmLAAAAAElFTkSuQmCC Date: Sat, 11 May 2013 12:47:48 +0800 In-Reply-To: (Stefan Monnier's message of "Fri, 10 May 2013 23:40:39 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2013-05-11 11:40 +0800, Stefan Monnier wrote: > But the generic completion code can't easily go down to a single call > in the general case. OK, if that is the case. I seem to recall that sometimes completion functions are invoked for getting the start and end positions only. Maybe this is an opportunity for optimisation. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 14:53: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136828393512320 (code B ref 11906); Sat, 11 May 2013 14:53:02 +0000 Received: (at 11906) by debbugs.gnu.org; 11 May 2013 14:52:15 +0000 Received: from localhost ([127.0.0.1]:36671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbB9i-0003Cf-JY for submit@debbugs.gnu.org; Sat, 11 May 2013 10:52:14 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41983) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbB9h-0003CY-57 for 11906@debbugs.gnu.org; Sat, 11 May 2013 10:52:13 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="11801616" Received: from 184-175-6-252.dsl.teksavvy.com (HELO pastel.home) ([184.175.6.252]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 11 May 2013 10:51:51 -0400 Received: by pastel.home (Postfix, from userid 20848) id 1E52067A1E; Sat, 11 May 2013 10:51:56 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Sat, 11 May 2013 10:51:56 -0400 In-Reply-To: (Leo Liu's message of "Sat, 11 May 2013 12:47:48 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> But the generic completion code can't easily go down to a single call >> in the general case. > OK, if that is the case. > I seem to recall that sometimes completion functions are invoked for > getting the start and end positions only. The completion-at-point-functions are called repeatedly (once after each command) to get the start/end, yes. But not the completion-table. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Andreas =?UTF-8?Q?R=C3=B6hler?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 20:26:01 +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: To: 11906@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.13683039585775 (code B ref -1); Sat, 11 May 2013 20:26:01 +0000 Received: (at submit) by debbugs.gnu.org; 11 May 2013 20:25:58 +0000 Received: from localhost ([127.0.0.1]:36855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbGMf-0001V4-MO for submit@debbugs.gnu.org; Sat, 11 May 2013 16:25:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41744) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbGMc-0001Uo-IA for submit@debbugs.gnu.org; Sat, 11 May 2013 16:25:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UbGMK-0002yC-6X for submit@debbugs.gnu.org; Sat, 11 May 2013 16:25:37 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-96.5 required=5.0 tests=BAYES_20, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_BL,USER_IN_WHITELIST autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:48615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbGMK-0002y1-3m for submit@debbugs.gnu.org; Sat, 11 May 2013 16:25:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53099) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbGMJ-0004I7-8u for bug-gnu-emacs@gnu.org; Sat, 11 May 2013 16:25:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UbGMI-0002xn-Gz for bug-gnu-emacs@gnu.org; Sat, 11 May 2013 16:25:35 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]:54123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UbGCk-0000CV-Ok for bug-gnu-emacs@gnu.org; Sat, 11 May 2013 16:15:43 -0400 Received: from [192.168.178.21] (brln-4dbc6de0.pool.mediaWays.net [77.188.109.224]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0Lsaqr-1UQRRV0fcH-012Kgq; Sat, 11 May 2013 22:15:40 +0200 Message-ID: <518EA77F.6030105@easy-emacs.de> Date: Sat, 11 May 2013 22:18:07 +0200 From: Andreas =?UTF-8?Q?R=C3=B6hler?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:vC052IGzkVR4Jrs7W+U1ThLmsTk99WhgIKN8bMPz1/s ot2nd7rMrFt+LLy9sBYDVyIHHgI7IFNlV8rKflCWyhDR1GTe8m 2K5RdHrBFqv0a5JZK97mN+t/oKLMVCg0jiWNgwwnLBodxHBh73 sHCExGWA6jSdEs6BaPgV6H+6I/5awaDEhF9uV+OH8N3bDF4pmG qNk/ggOT8bf/MpAMQ8jeFX5eMCsFTfuM6AwkDHYUzShne80T2M ssJi0cHL5yWCdCYaevZmv9/BCSrqSlwIv8X8gIbLCHMhQlrGT+ WPhAXRdm0l0s+i2rognYPOyZJMGLG/ZFHHGBDFzOGRBbsxUeQ4 d2/MNOoHaceGVzzLIowoSVG9MfOmcm5yNEtxtlNux X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -5.5 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.9 (------) Am 11.05.2013 06:47, schrieb Leo Liu: > On 2013-05-11 11:40 +0800, Stefan Monnier wrote: >> But the generic completion code can't easily go down to a single call >> in the general case. > > OK, if that is the case. > > I seem to recall that sometimes completion functions are invoked for > getting the start and end positions only. Maybe this is an opportunity > for optimisation. > > Leo > > > > Hi Leo, from what I've seen some weeks ago, just signaling my interest. Seems a promising point to push things forwards. Thanks all, Andreas From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Daimrod Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 11 May 2013 23:10: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: To: Stefan Monnier Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.1368313770392 (code B ref 11906); Sat, 11 May 2013 23:10:02 +0000 Received: (at 11906) by debbugs.gnu.org; 11 May 2013 23:09:30 +0000 Received: from localhost ([127.0.0.1]:36949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbIuv-00006E-Ny for submit@debbugs.gnu.org; Sat, 11 May 2013 19:09:30 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:34757) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbIus-000060-Rf for 11906@debbugs.gnu.org; Sat, 11 May 2013 19:09:28 -0400 Received: by mail-wi0-f174.google.com with SMTP id m6so1737765wiv.13 for <11906@debbugs.gnu.org>; Sat, 11 May 2013 16:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=lrfpUWk/PK1YOeiOcycYln4qWqJCoCf1Pw3bzd6oxyc=; b=inCV2vjxRrqaG8h+F8TZOAaKO0I0dkC6bAG8H8OyeqjrrW6wUktilOBxsuaxo8wuX1 36PRHr481hwX1kskp0mWUC4i6ZjQZgM1Wy1rDdOWYsvXk3y/Pk/3OjpDsa72WD1TAj/k D8Wvqcq278oZEoJcieBy5Moay9lkGaeSOXXi+SiooYgCs+mmfBCLxdt01j9QBsYxramE 0jX4vOM7A/YaLNp8P+ocZXTLd6KXs5u4vxQP9/okvMUntlULKsFSjVF3YEhR2SKm/WjT bo9qn8ZUtQZ88J3vV6MY/tg0mheTdk8kT+Vn2PLF6lJNf1eRiEH53TOp2nbH0c6jvyS9 Jkgg== X-Received: by 10.180.88.162 with SMTP id bh2mr10923290wib.3.1368313747832; Sat, 11 May 2013 16:09:07 -0700 (PDT) Received: from localhost (ANantes-653-1-136-93.w2-0.abo.wanadoo.fr. [2.0.247.93]) by mx.google.com with ESMTPSA id q20sm7013191wiv.7.2013.05.11.16.09.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 11 May 2013 16:09:07 -0700 (PDT) From: Daimrod References: Date: Sun, 12 May 2013 01:11:48 +0200 In-Reply-To: (Stefan Monnier's message of "Fri, 10 May 2013 23:40:39 -0400") Message-ID: <871u9djemj.fsf@tanger.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. > >> 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. > > 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. Hello, Maybe I didn't understand what you mean, but AFAIK it's already available. You can compute a list of possible completions only once and then return a completion table (start end COLLECTION) where collection is a function described here (info "(elisp) Programmed Completion"). =2D-=20 Daimrod/Greg --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRjtA6AAoJEBNzVHcrZRiUD24QAIRDv0vJ8BoZad3LxuKVy/7x QIHY09TyuMwid+boPGH8iEXVT6ZI9dhbP2XyEakugmGBylrYL/wFl6Bk2Ou4f/Go uhJ3kjHy1A3mdgA/x2Z0trn+MmX8O7HZpFYEP/gYa2lA/bNlOampk4As+if2FOgc YrqWnxO01dbx4f6WZsUDDTYTlNEolBrNv2gcOa4Hv2mBSu8kARa8soRJ+RpY4wnT Ctw5NHm4dOekZHSWANfJ85TX58rWK2r9skdZWXE7lftEdTeRPbH+7/C/XCJEh4fd 1eQ7E3+5JmhDaFnL3RDXvM2nYB0uN7OScn79sXCmWKqAL6KD4mUM2sOWhQTi6OQG 3XHJvb2UFTwwpv7/QafWQE0Sr7ZN0IWUQI+IMy69tVPRjzOOOTLZWX0suHJinE5E lJ2fOLzzj1eN6V8Df5uFm+UfDs9fLTOIZsLQlqCN4YaFXEq8Qk3+gwFMTylj2LVu 0Eo1XktisHrNrEV7kZsHs/YDoWmARc1q/InjHsNV5GFZ9pJiJqpOLAbxXuAAGxTk WGiS5iCxNv9To0vvfJOxFzVCD3/DMvpztnju9uu5G5vK4iPgyjEBPTyz9NHNyA1v IAenBxl4CaiKnPcx+/2KzPisX3gkEDGxBb/vPA/D0kU1DYCPIQSZy6upQztL3kSO JLZXepUyNAN8cODv5eQY =5r8K -----END PGP SIGNATURE----- --=-=-=-- From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 May 2013 01:29:01 +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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136840853915068 (code B ref 11906); Mon, 13 May 2013 01:29:01 +0000 Received: (at 11906) by debbugs.gnu.org; 13 May 2013 01:28:59 +0000 Received: from localhost ([127.0.0.1]:37930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbhZS-0003uz-BT for submit@debbugs.gnu.org; Sun, 12 May 2013 21:28:58 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:64684) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbhZQ-0003ur-5Q for 11906@debbugs.gnu.org; Sun, 12 May 2013 21:28:57 -0400 Received: by mail-pd0-f179.google.com with SMTP id q10so4014881pdj.10 for <11906@debbugs.gnu.org>; Sun, 12 May 2013 18:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=X+lhC4nNl8bvvyHeVsyI4oXEuDNIbg4K0/ulvFlaS30=; b=RjvA5ZlFtzwxVCwUTbq5RASDvuVkRGm7Imd16pwBW1KxZ+7I70S/Ntl242JJTxNByJ RzzYJztOpPrDrliL5lQ5NHW35E7dHdbmYx7P2I/e7qEwo37Dszv1JZD0aD0I4a1nanhN gZniEpq9ra/lFSFn/UPuoXyqgRXse9bjoLojCfKG2yLPR1bNpCNR/G7sI10L05DrzezW QixdAACPF2F5y8v3opVTLjIOmTzpz6o9D6GuRIyJ3mS7iYcT3GBWjtHrau47HZmKU9SZ rPb77xKFy99fIR5iY9litGWnILZraNVZmSn6Ds7l+ZAK5LXZA/wZBxuUNCMuWx0QH6Tx 0N0A== X-Received: by 10.68.179.35 with SMTP id dd3mr26618891pbc.197.1368408511184; Sun, 12 May 2013 18:28:31 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id qb1sm11794730pbb.33.2013.05.12.18.28.28 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 12 May 2013 18:28:30 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUKDAg1NjRWV1V9fnyg op/DxcLk5uP8/voi63ReAAAACXBIWXMAAAWJAAAFiQFtaJ36AAAAB3RJTUUH1goZAgAz00bgXgAA AeVJREFUKM9lk0Fz2jAQhQXJD3CCO70CmcC1YMtcWyTZ14Bl69xats4N9r6/3zWQBlodNKNPu/s0 b1cCQFuZGpfVVh3vAvBJolIXRkapSuoRUtIdFyo1Y5xSdlAj7OtvD1XnXxmWRi+eWgcxyCed1lVV B1CrKyujMoi+eLA5kU1SsjoHlW+nQjTtFxk4MXgrOxvIqzoTZR8XgPaLl419zgsMaSGFPiUOZCIh thsx5Xy9NsK8Kwf/JoQgMxcVJ301HKkcSWaT0O7FY056J4U9xcYfnmVXG4801lW6lqwu2nKFZoHC HuzvaTVndZ+LaRQgZdthXw1cpynEkLEwyFHXk/aIxNQ6QeooJuzPMB+wn+D7JJNsiCcVA13/A3h/ xE9J+WidpAwoYNmRFwyvSRhNVtsdaAewzZZP5uw82QL9+tyNfocyP0McAzICUr5Mk9RdIjWasUNx aIIt6NK4ZtXIMdfMQt3nuMAyWbLI4DqZ4xPq/ag8jPond4XU/cLuOgw6XCFX/YCUfcDAMMH58fD4 G9kDchwfqVefkBwup2uZM+Q4WhJt5jN3AxXCsaS2yXEDuWgS8VOzW0gFjhEPmLyFMKBFaLb1HRwc DiaKwx0EeTMRYnYPQRW3PP4HApvlMv0PttX5v/D6Aws3IOSEwzmLAAAAAElFTkSuQmCC Date: Mon, 13 May 2013 09:28:23 +0800 In-Reply-To: (Stefan Monnier's message of "Sat, 11 May 2013 10:51:56 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 2013-05-11 22:51 +0800, Stefan Monnier wrote: > The completion-at-point-functions are called repeatedly (once after each > command) to get the start/end, yes. But not the completion-table. How about a special variable `completion-requires-no-table' that costly completion functions can take advantage of the opportunity? Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 May 2013 15:29: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136845890123122 (code B ref 11906); Mon, 13 May 2013 15:29:02 +0000 Received: (at 11906) by debbugs.gnu.org; 13 May 2013 15:28:21 +0000 Received: from localhost ([127.0.0.1]:38764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ubufk-00060r-Ow for submit@debbugs.gnu.org; Mon, 13 May 2013 11:28:21 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:46224) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ubufj-00060h-6k for 11906@debbugs.gnu.org; Mon, 13 May 2013 11:28:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="11910353" Received: from 184-175-6-252.dsl.teksavvy.com (HELO pastel.home) ([184.175.6.252]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 May 2013 11:27:46 -0400 Received: by pastel.home (Postfix, from userid 20848) id 3FB9A67B0D; Mon, 13 May 2013 11:27:50 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Mon, 13 May 2013 11:27:50 -0400 In-Reply-To: (Leo Liu's message of "Mon, 13 May 2013 09:28:23 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> The completion-at-point-functions are called repeatedly (once after each >> command) to get the start/end, yes. But not the completion-table. > How about a special variable `completion-requires-no-table' that costly > completion functions can take advantage of the opportunity? I do not understand what that variable would do. Can you give some more details? Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 May 2013 15:29: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: To: Daimrod Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136845893823228 (code B ref 11906); Mon, 13 May 2013 15:29:02 +0000 Received: (at 11906) by debbugs.gnu.org; 13 May 2013 15:28:58 +0000 Received: from localhost ([127.0.0.1]:38767 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbugM-00062b-6i for submit@debbugs.gnu.org; Mon, 13 May 2013 11:28:58 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:36447) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UbugK-00062S-Iq for 11906@debbugs.gnu.org; Mon, 13 May 2013 11:28:56 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IPAS-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="11910415" Received: from 184-175-6-252.dsl.teksavvy.com (HELO pastel.home) ([184.175.6.252]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 May 2013 11:28:24 -0400 Received: by pastel.home (Postfix, from userid 20848) id 5D8B667B0D; Mon, 13 May 2013 11:28:28 -0400 (EDT) From: Stefan Monnier Message-ID: References: <871u9djemj.fsf@tanger.home> Date: Mon, 13 May 2013 11:28:28 -0400 In-Reply-To: <871u9djemj.fsf@tanger.home> (daimrod@gmail.com's message of "Sun, 12 May 2013 01:11:48 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> 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. > Maybe I didn't understand what you mean, but AFAIK it's already > available. You can compute a list of possible completions only once and > then return a completion table (start end COLLECTION) where collection > is a function described here (info "(elisp) Programmed Completion"). That's just the easy part of writing a cached completion table. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 May 2013 00:58: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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13684930548972 (code B ref 11906); Tue, 14 May 2013 00:58:02 +0000 Received: (at 11906) by debbugs.gnu.org; 14 May 2013 00:57:34 +0000 Received: from localhost ([127.0.0.1]:39176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc3Yb-0002Kf-OL for submit@debbugs.gnu.org; Mon, 13 May 2013 20:57:33 -0400 Received: from mail-pa0-f44.google.com ([209.85.220.44]:35510) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc3YZ-0002KU-3N for 11906@debbugs.gnu.org; Mon, 13 May 2013 20:57:31 -0400 Received: by mail-pa0-f44.google.com with SMTP id jh10so30819pab.3 for <11906@debbugs.gnu.org>; Mon, 13 May 2013 17:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=aCp0feqlXZJK6ukBLMvYIJ03HhILlr/9FklfbHfBMUg=; b=kGtxBiFFUYQxPp74RGqXkPBG0qdT2s4yDQsflzgs8bs56dbRO6i8146KJD+tGICLi5 QjGo7umo/G1v6qS8USlA4P1Wq0YdwWq085M36cZR84WnYc2jSWloIatPOxiLGRRpoOYJ Ei72m8sz2vfH6IwUAo81H6HvosnjomPIZ/rjFMd3C9n5YcE5Pm2AbYYyxTyDsBVq7TEp wQLufZ3M4/3XpmE3fLZkRlOVyN+G0ZDu24ssL94YGyB6eTbdWbmRc/pG0eghFUMSy9UO 6iulrxxnH38QlK/u2GcVfb/lPOao01nTcWgApRxyLD1oVS1ZVl+2EkM2axbICd24mnBF 28IA== X-Received: by 10.66.20.234 with SMTP id q10mr27953765pae.201.1368493020246; Mon, 13 May 2013 17:57:00 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id t1sm16898831pab.12.2013.05.13.17.56.57 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 17:56:59 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUzRVhbQj4eZqO6SjnT eWpxnMetm5b6/PmidmqrAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1F B9cBBwMLBfKABCMAAAFoSURBVCjPtZI9a8MwEIaFoc7aYDdelQMna0Em3tsSr0XUeE2Q6a22a+v+ fk8fSSBkbDUI6dHpfe9OEvRgiD+ApqKPJgJeB6iUUXWESjUe/ig38AJrhqqvaU2nTIXbNvOQ40fe qdry4kyGoVWsfCQalXpHnJGM01wjWdYbMlXNFdsZDO69m9aqNqxEJqTEgbM5OF7wlEfIoll1Ked4 LbM5X2EdILLokEdmI8z7g5cKED0cuTC930TYhy7ZDekkXVGw/L60TguJePPxcJF48lpsSUWEA/Ju jGFNgJOXc4Hz7TmAdBeu5Ve4AEjOi2/2jfd3cAJZ+IbNrvdjgBZY01b+HTuG3cLws6BJZqVOj/pp T0OqVwx3rFq+QmJwx3loK5JSLEhDIt62+mtC2C+SrAUxEbV6C6v2BRbd6pILBKFpepKZJHgGgrKF sptSUUoczpwg2pQ7ZH1tgs0ou/917mzz6Cs2//C978cv5l07L02orIEAAAAASUVORK5CYII= Date: Tue, 14 May 2013 08:56:53 +0800 In-Reply-To: (Stefan Monnier's message of "Mon, 13 May 2013 11:27:50 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.6 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 2013-05-13 23:27 +0800, Stefan Monnier wrote: > I do not understand what that variable would do. Can you give some > more details? Places that need no completion table should bind completion-requires-no-table to t before calling the completion-at-point-functions. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 May 2013 02:55:01 +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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136850005226735 (code B ref 11906); Tue, 14 May 2013 02:55:01 +0000 Received: (at 11906) by debbugs.gnu.org; 14 May 2013 02:54:12 +0000 Received: from localhost ([127.0.0.1]:39231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc5NT-0006x8-Nn for submit@debbugs.gnu.org; Mon, 13 May 2013 22:54:11 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:2330) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc5NR-0006wx-Cm for 11906@debbugs.gnu.org; Mon, 13 May 2013 22:54:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2OLoJcA6R6gV6Caik X-IPAS-Result: Av4EABK/CFG4rwb8/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2OLoJcA6R6gV6Caik X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="11960726" Received: from 184-175-6-252.dsl.teksavvy.com (HELO pastel.home) ([184.175.6.252]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 May 2013 22:53:33 -0400 Received: by pastel.home (Postfix, from userid 20848) id D543C67B0D; Mon, 13 May 2013 22:53:37 -0400 (EDT) From: Stefan Monnier Message-ID: References: Date: Mon, 13 May 2013 22:53:37 -0400 In-Reply-To: (Leo Liu's message of "Tue, 14 May 2013 08:56:53 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >> I do not understand what that variable would do. Can you give some >> more details? > Places that need no completion table should bind > completion-requires-no-table to t before calling the > completion-at-point-functions. Makes no sense to me: the completion-table object should always be "trivial" to build. At least, that's always been the case so far. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 May 2013 03:32: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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.1368502286569 (code B ref 11906); Tue, 14 May 2013 03:32:02 +0000 Received: (at 11906) by debbugs.gnu.org; 14 May 2013 03:31:26 +0000 Received: from localhost ([127.0.0.1]:39252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc5xW-000094-6g for submit@debbugs.gnu.org; Mon, 13 May 2013 23:31:26 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:50779) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Uc5xU-00008v-8C for 11906@debbugs.gnu.org; Mon, 13 May 2013 23:31:24 -0400 Received: by mail-pd0-f182.google.com with SMTP id 3so45448pdj.13 for <11906@debbugs.gnu.org>; Mon, 13 May 2013 20:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:face:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=eR/wIWbvMhLPYiHLihc2xMLRDy2l9dVGoZBBS4GDRhI=; b=c7HOFUtWoWoTMKUdLJbnRYc5S/pbhjlBU/k/NFhxFzZzUtc0PFTOdqmFA+tCiJxkzG hM4Ej8f19pSayC96GGPkT62Shb/RlxsNq4c6rFZ5CRdgV5wfnC6oeF2JpUcYdtU2LwAo H1ZW9BL/XBPtXUvBQEQp0d3HNkPsDWRe0sfiiHkhDUGa41PlGdWq12W1Dw5ATSv5kVal SDD0sWYAdkdo7sx4nIUN5pCkiOTRsN0nEOjsWJNo8dHPxAeUiU2X5XnNDi1BY2R6anZO SJ9HjKWE4pXL3ELvjxItQtN9uyCRfQu+YELWJiVHwZ4QvSS46v9NFAcml/9c7dIlkxa5 Yddw== X-Received: by 10.68.248.100 with SMTP id yl4mr31686079pbc.125.1368502253087; Mon, 13 May 2013 20:30:53 -0700 (PDT) Received: from Zeuss-MacBook.local (li511-224.members.linode.com. [66.175.216.224]) by mx.google.com with ESMTPSA id sq9sm17398000pab.5.2013.05.13.20.30.50 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 20:30:52 -0700 (PDT) From: Leo Liu References: Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoAgMAAADxkFD+AAAADFBMVEUvT09qWs3/pQD///+J kUVcAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMLOd3veKQA AACuSURBVBjTldE9CgIxEAXgB+lEyFUC2wo5ikdZ8DSypxhMY7H9VuIVwlqkGRgnm59VsHGafIQ3 CZlAtmKIRaHETgYa12lqvEsPYKf8wXHsPGfqPaUM0g9aJPKFXkmNQmSDqwzz4Fpgpz+6WAPY2z5o uPJJpu0uypcl4nyCibMLQ8lCiVjayLoQvw5LsVKQuHPRR958HZbOcVsKeepcLxpByjycGvnKmY+c MBvrtyjfe0vmuLvdq/kAAAAASUVORK5CYII= Date: Tue, 14 May 2013 11:30:45 +0800 In-Reply-To: (Stefan Monnier's message of "Mon, 13 May 2013 22:53:37 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.8.3) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 2013-05-14 10:53 +0800, Stefan Monnier wrote: > Makes no sense to me: the completion-table object should always be > "trivial" to build. At least, that's always been the case so far. OK. In that case I'll leave this off for now until I have more time to go through minibuffer.el. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures 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: To: Stefan Monnier Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136917960726497 (code B ref 11906); Tue, 21 May 2013 23:41:02 +0000 Received: (at 11906) by debbugs.gnu.org; 21 May 2013 23:40:07 +0000 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 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 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) 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) From: Dmitry Gutov References: Date: Wed, 22 May 2013 03:39:13 +0400 In-Reply-To: (Stefan Monnier's message of "Fri, 10 May 2013 23:40:39 -0400") Message-ID: <87li776gym.fsf@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Antivirus: avast! (VPS 130521-1, 21.05.2013), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) 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'. From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 May 2013 19:17: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: To: Dmitry Gutov Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.136925021729191 (code B ref 11906); Wed, 22 May 2013 19:17:02 +0000 Received: (at 11906) by debbugs.gnu.org; 22 May 2013 19:16:57 +0000 Received: from localhost ([127.0.0.1]:56665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UfEWv-0007am-9T for submit@debbugs.gnu.org; Wed, 22 May 2013 15:16:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.182]:28068) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UfEWt-0007aP-ID for 11906@debbugs.gnu.org; Wed, 22 May 2013 15:16:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFpZoF/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IPAS-Result: Av4EABK/CFFFpZoF/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="14142418" Received: from 69-165-154-5.dsl.teksavvy.com (HELO ceviche.home) ([69.165.154.5]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 May 2013 15:15:58 -0400 Received: by ceviche.home (Postfix, from userid 20848) id A361566107; Wed, 22 May 2013 15:16:01 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87li776gym.fsf@yandex.ru> Date: Wed, 22 May 2013 15:16:01 -0400 In-Reply-To: <87li776gym.fsf@yandex.ru> (Dmitry Gutov's message of "Wed, 22 May 2013 03:39:13 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) >>>> 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? Because the first call is for try-completion (i.e. "give me the completion") and the second is for all-completions (i.e. "give me all matching candidates"), so the info returned by the first call is not sufficient to avoid the second call. As you've seen there can be a second call (to try-completion with the result of the first call to try-completion) to check if the completion is unique. Plus another call (to test-completion) to check if the result of the first try-completion was complete. > So, suppose we do provide a caching function. Would it cache more than > just one pair? Probably, yes. It would turn test-completion and try-completion into calls to all-completions and then cache one "arg+result" of all-completions (this pair would be sufficient to cover all calls to test/try/all-completion for any argument string which has `arg' as its prefix). > 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'. Right, that's the idea. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2013 03:24: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: To: Stefan Monnier Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138621383014027 (code B ref 11906); Thu, 05 Dec 2013 03:24:02 +0000 Received: (at 11906) by debbugs.gnu.org; 5 Dec 2013 03:23:50 +0000 Received: from localhost ([127.0.0.1]:58691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoPXZ-0003eB-NI for submit@debbugs.gnu.org; Wed, 04 Dec 2013 22:23:50 -0500 Received: from mail-ea0-f171.google.com ([209.85.215.171]:52748) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoPXW-0003e0-FK for 11906@debbugs.gnu.org; Wed, 04 Dec 2013 22:23:47 -0500 Received: by mail-ea0-f171.google.com with SMTP id h10so11086853eak.16 for <11906@debbugs.gnu.org>; Wed, 04 Dec 2013 19:23:45 -0800 (PST) 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; bh=SrcKdBBaaeOqLgupWYnR00/q+dUGnNMSEAtcGjpU9O4=; b=rOklNRWfeohaUu7dj0etkeRDB9XC1fqZUsQ7f4LGedct9zZY6Zdi1lRxT8KCFEFfUn iSKFP8XL9cKA5CE3ArsknDaHotkYcsDRrq5jMryb9g8fw4ZAV6perlCMizt9QtSxnKjP 29pTxV5c37yzTAjjy8+upMOfo7BQjRhLDew99hsNpzp0OiUkGuwcU6xBA00EfU670rd6 Ful6c7djlmRn2mkC3fmMydi2HdpRC4zrusi0g+va7owQ2KPmzYmfONN4n2r0VVxuhPqL fp/TIKd/qMu2I90HAU9117IHD4Ma3KRQXwu6lINbz1Dv29AqKgdMf8iwjK/fkTPey1yX KO1Q== X-Received: by 10.14.119.136 with SMTP id n8mr10041131eeh.82.1386213825409; Wed, 04 Dec 2013 19:23:45 -0800 (PST) Received: from axl ([62.228.136.233]) by mx.google.com with ESMTPSA id p45sm11039711eeg.1.2013.12.04.19.23.43 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 04 Dec 2013 19:23:44 -0800 (PST) From: Dmitry Gutov References: <87li776gym.fsf@yandex.ru> Date: Thu, 05 Dec 2013 05:23:37 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 22 May 2013 15:16:01 -0400") Message-ID: <87pppcasli.fsf@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --=-=-= Content-Type: text/plain Stefan Monnier writes: > Probably, yes. It would turn test-completion and try-completion into > calls to all-completions and then cache one "arg+result" of > all-completions (this pair would be sufficient to cover all calls to > test/try/all-completion for any argument string which has `arg' as its > prefix). How does this patch look? (The Octave part is 100% untested). --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=completion-table-with-cache.diff === modified file 'lisp/minibuffer.el' --- lisp/minibuffer.el 2013-11-24 14:08:02 +0000 +++ lisp/minibuffer.el 2013-12-05 03:22:09 +0000 @@ -190,6 +190,24 @@ (current-buffer))) (complete-with-action action (funcall fun string) string pred))))) +(defun completion-table-with-cache (fun &optional ignore-case) + "Create dynamic completion table from FUN, with cache. +This wraps `completion-table-dynamic', but saves the last +argument-result pair from FUN, so that several lookups with the +same argument (or with an argument that starts with the first one) +only need to call FUN once. Most useful when FUN performs a relatively +slow operation, such as calling an external process (see Bug#11906). +When IGNORE-CASE is non-nil, FUN is expected to be case-insensitive." + (let* (last-arg last-result + (new-fun + (lambda (arg) + (if (and last-arg (string-prefix-p last-arg arg ignore-case)) + last-result + (prog1 + (setq last-result (funcall fun arg)) + (setq last-arg arg)))))) + (completion-table-dynamic new-fun))) + (defmacro lazy-completion-table (var fun) "Initialize variable VAR as a lazy completion table. If the completion table VAR is used for the first time (e.g., by passing VAR === modified file 'lisp/progmodes/octave.el' --- lisp/progmodes/octave.el 2013-12-02 07:13:01 +0000 +++ lisp/progmodes/octave.el 2013-12-05 03:15:06 +0000 @@ -838,21 +838,13 @@ ;; `comint-history-isearch-backward-regexp'. Bug#14433. (comint-send-string proc "\n"))) -(defvar inferior-octave-completion-table - ;; - ;; Use cache to avoid repetitive computation of completions due to - ;; bug#11906 - http://debbugs.gnu.org/11906 - which may cause - ;; noticeable delay. CACHE: (CMD . VALUE). - (let ((cache)) - (completion-table-dynamic - (lambda (command) - (unless (equal (car cache) command) - (inferior-octave-send-list-and-digest - (list (format "completion_matches ('%s');\n" command))) - (setq cache (cons command - (delete-consecutive-dups - (sort inferior-octave-output-list 'string-lessp))))) - (cdr cache))))) +(defun inferior-octave-completion-table () + (completion-table-with-cache + (lambda (command) + (inferior-octave-send-list-and-digest + (list (format "completion_matches ('%s');\n" command))) + (delete-consecutive-dups + (sort inferior-octave-output-list 'string-lessp))))) (defun inferior-octave-completion-at-point () "Return the data to complete the Octave symbol at point." @@ -864,7 +856,7 @@ (end (point))) (when (and beg (> end beg)) (list beg end (completion-table-in-turn - inferior-octave-completion-table + (inferior-octave-completion-table) 'comint-completion-file-name-table)))))) (define-obsolete-function-alias 'inferior-octave-complete @@ -1022,7 +1014,7 @@ (completing-read (format (if def "Function (default %s): " "Function: ") def) - inferior-octave-completion-table + (inferior-octave-completion-table) nil nil nil nil def))) (defun octave-goto-function-definition (fn) @@ -1406,7 +1398,7 @@ (setq end (point)))) (when (> end beg) (list beg end (or (and (inferior-octave-process-live-p) - inferior-octave-completion-table) + (inferior-octave-completion-table)) octave-reserved-words))))) (define-obsolete-function-alias 'octave-complete-symbol --=-=-=-- From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Dec 2013 04:35: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: To: Dmitry Gutov Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138621805525171 (code B ref 11906); Thu, 05 Dec 2013 04:35:02 +0000 Received: (at 11906) by debbugs.gnu.org; 5 Dec 2013 04:34:15 +0000 Received: from localhost ([127.0.0.1]:58733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoQdi-0006Xu-Ay for submit@debbugs.gnu.org; Wed, 04 Dec 2013 23:34:14 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:52883) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VoQdg-0006Xl-2O for 11906@debbugs.gnu.org; Wed, 04 Dec 2013 23:34:12 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxL6g/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFxL6g/2dsb2JhbABEvw4Xc4IeAQEEAVYjEAsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="41185115" Received: from 69-196-190-160.dsl.teksavvy.com (HELO pastel.home) ([69.196.190.160]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Dec 2013 23:34:06 -0500 Received: by pastel.home (Postfix, from userid 20848) id 7909E60F5D; Wed, 4 Dec 2013 23:33:59 -0500 (EST) From: Stefan Monnier Message-ID: References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> Date: Wed, 04 Dec 2013 23:33:59 -0500 In-Reply-To: <87pppcasli.fsf@yandex.ru> (Dmitry Gutov's message of "Thu, 05 Dec 2013 05:23:37 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> Probably, yes. It would turn test-completion and try-completion into >> calls to all-completions and then cache one "arg+result" of >> all-completions (this pair would be sufficient to cover all calls to >> test/try/all-completion for any argument string which has `arg' as its >> prefix). > How does this patch look? > (The Octave part is 100% untested). Looks OK, thank you. We may want to extend it at some point with a predicate that can test if the cache is stale, but for now it's probably good enough. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 01:03:01 +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: To: Stefan Monnier Cc: Leo Liu , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138629174826816 (code B ref 11906); Fri, 06 Dec 2013 01:03:01 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 01:02:28 +0000 Received: from localhost ([127.0.0.1]:60823 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VojoJ-0006yR-Uj for submit@debbugs.gnu.org; Thu, 05 Dec 2013 20:02:28 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:57501) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VojoH-0006yH-Ig for 11906@debbugs.gnu.org; Thu, 05 Dec 2013 20:02:26 -0500 Received: by mail-wg0-f49.google.com with SMTP id x12so19514wgg.4 for <11906@debbugs.gnu.org>; Thu, 05 Dec 2013 17:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wMcmc6++NLHwPOIO36mWRBsolehJGyHbBM9BHrteLeg=; b=L6RBIa5pxFpEhqwBTmnbMKA7cYb2o7JT8nLTOSiD/NnquOsEWpU9z1h+fGtY2TMhlQ pZz846WW1LoAwTkCp1Du56laQH7S0Wqr06F9lrmjFMJvJ675JIoTgYMFRiwXFfBRYh4g uoA+AJAXUE6gXui+psGl1599Mt2+Im0dakwx3xvkofCSW1oMEUS4JSYAzJhz/uDNIeFK HB3EUd8hKTVvdV4btQwZ6W2AWeRzS6KO20/l3hS94zJOwTvoBvlpGqN1s2HrRf+LFv96 pMYp4Nx+TZX+DlzlXxIHwB8MiuztpqqPqHEq2yhLD2HjY1UrnyQMD0DQ0RYWr2ZCSnOK U/gg== X-Received: by 10.194.1.139 with SMTP id 11mr566548wjm.33.1386291744767; Thu, 05 Dec 2013 17:02:24 -0800 (PST) Received: from [192.168.10.2] ([62.228.136.233]) by mx.google.com with ESMTPSA id w20sm1269926wia.5.2013.12.05.17.02.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 17:02:23 -0800 (PST) Message-ID: <52A1221D.90501@yandex.ru> Date: Fri, 06 Dec 2013 03:02:21 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05.12.2013 06:33, Stefan Monnier wrote: > Looks OK, thank you. Installed, seems to work fine. > We may want to extend it at some point with > a predicate that can test if the cache is stale, but for now it's > probably good enough. Probably, but for its primary usage (amortizing the 2-3 lookups `completion-at-point' does) even the `string-prefix-p' check is redundant, just as long as we create a new completion-table each time our completion-at-point function is called, and not cache it in a var. Leo, do you consider this bug fixed now, or would you like to provide a reproduction scenario for the ObjC selector completion cycling problem, mentioned in the initial report? From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 04:02:01 +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: To: Dmitry Gutov Cc: Stefan Monnier , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138630246211506 (code B ref 11906); Fri, 06 Dec 2013 04:02:01 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 04:01:02 +0000 Received: from localhost ([127.0.0.1]:60977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vomb7-0002zT-UK for submit@debbugs.gnu.org; Thu, 05 Dec 2013 23:01:02 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:43878) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vomb5-0002z6-Ua for 11906@debbugs.gnu.org; Thu, 05 Dec 2013 23:01:00 -0500 Received: by mail-pb0-f41.google.com with SMTP id jt11so297130pbb.0 for <11906@debbugs.gnu.org>; Thu, 05 Dec 2013 20:00:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=HbF3mZFcx01zy2ry1/E1a7siysxou7t93Pm55mwKun0=; b=pqWNwNiQNffdoe6+sscKUIUdgUZ3jYBGxFKm5WjhQWpJQCcw2hAZ8SKsfgpIHO5JjA 5burWUfPXPUf7jV8y+P9XQZpTA1uJy73joiVDwWPhvIjiFSP77867c3VkNeekb7pgfJ3 L8QA7ysHwUnux5KR30BjJn8lADrTIWLRM90oY8PkFnS8rGWpOUF6xRooATv7Ka7SUMpq rjfLB/6DMgl/V5TToUMcVfWdRxgMTm7rxmcBNjuOB9vifM+phlyYMRF/Itcl+qzGr22j 4+DikJeElJC9u4wTnoFEwRmND2sHW8X3q3DYerSUvGSNI71voUo6hUc/ODYTfsY+fTjF CV7w== X-Received: by 10.68.217.194 with SMTP id pa2mr1473464pbc.1.1386302458785; Thu, 05 Dec 2013 20:00:58 -0800 (PST) Received: from localhost ([123.119.93.169]) by mx.google.com with ESMTPSA id nn6sm96944560pbc.29.2013.12.05.20.00.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2013 20:00:58 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAElBMVEUAAAAAAP+LRRP0pGC+ vr7///+7mT1iAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMO DhglKe4AAAEsSURBVCjPbZNBboQwDEV/Cd4X9QJRThApmn0XYW+Jyf2v0m+HhqDBgiAe9rcTG7QH w/1Vn2Ar8gBb/ocywSN3qK9T3z4eFDB4eApocBpeBs1RSykoJd8gQcm8pGmHXFso3ajnmsqV0TnY DQkOfXUfN5NwaI7AWTVOyEhcu1aHmdWItHddUVUcUgUBCkitu8V6ditHVOVdqzl2EQ1ZVGTbdK0V 7cqn8vWzoU5Q/bF9Y/Y0cRU1xwkys5dJ+Dt6pBDWifcNQml8Gh2JVmPSoQzo7en0grswkxrUGYJ7 0hSxxAGr7ZMwYcHIzprpi7TENEE1xtiYxixRlCfPBsUUrwHD7uGIwATrbnODJcVrPpVn3hxiGloe m/S+z3CtuzUSMo83N4DPH+F0evwR3P4A2k+75838OKQAAAAASUVORK5CYII= Date: Fri, 06 Dec 2013 12:00:52 +0800 In-Reply-To: <52A1221D.90501@yandex.ru> (Dmitry Gutov's message of "Fri, 06 Dec 2013 03:02:21 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2013-12-06 09:02 +0800, Dmitry Gutov wrote: > Leo, do you consider this bug fixed now, or would you like to provide > a reproduction scenario for the ObjC selector completion cycling > problem, mentioned in the initial report? I see the solution has gone down in a different route. My intention was to fix/avoid inefficiency in minibuffer.el in the first place. The code in minibuffer.el knows perfectly well when it doesn't need a completion table and should provide a way to notify completion-at-point-functions so that they can simplify ignore such computation. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 04:33:01 +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: To: Leo Liu Cc: Stefan Monnier , 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138630434114431 (code B ref 11906); Fri, 06 Dec 2013 04:33:01 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 04:32:21 +0000 Received: from localhost ([127.0.0.1]:32776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Von5Q-0003kg-2U for submit@debbugs.gnu.org; Thu, 05 Dec 2013 23:32:20 -0500 Received: from mail-wg0-f44.google.com ([74.125.82.44]:60093) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Von5O-0003kY-CA for 11906@debbugs.gnu.org; Thu, 05 Dec 2013 23:32:18 -0500 Received: by mail-wg0-f44.google.com with SMTP id a1so140922wgh.35 for <11906@debbugs.gnu.org>; Thu, 05 Dec 2013 20:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D4Ddy3UIOySs5+kOpaZAaFbLY7Tvib/CBCcjaeu94Tg=; b=SR6afuVHZB70SikiREjwoPumr2B5BjP8Tt5Egu89v66nEd3P8YuvQExtYulru0OWmd PJp/DOzylhPWLsfb6pNnEdL9u1jItUA+NEL7mXYVAJGjjvND951BTWaR7DbcrHw657qT x7boNaZ1WAv+tHVZsne2bGtSVG88I/lxje6tQx37zNZuf2TMqaGXI0IWjGtmCDq775PR o6Bw1+YHpMDepNpV3i2vxi4VBRqrBpB2F9yHjsc1pp6ldiRg544s89cdySyKp5py/1ex nxylVxv2TSBVv1+LnydLwX4HPb+AvYZ2EXxMwiRhEIKfKfzUOVthrpb+n8whIn9ZzJQi j51w== X-Received: by 10.180.12.70 with SMTP id w6mr617719wib.4.1386304337204; Thu, 05 Dec 2013 20:32:17 -0800 (PST) Received: from [192.168.10.2] ([62.228.136.233]) by mx.google.com with ESMTPSA id dn2sm2476699wid.1.2013.12.05.20.32.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 20:32:16 -0800 (PST) Message-ID: <52A1534D.3000902@yandex.ru> Date: Fri, 06 Dec 2013 06:32:13 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 06.12.2013 06:00, Leo Liu wrote: > The code in minibuffer.el knows perfectly well when it doesn't need a > completion table and should provide a way to notify > completion-at-point-functions so that they can simplify ignore such > computation. I don't understand what you mean by "doesn't need a completion table". Could you give an example? If some function doesn't need it, why does it use it? There should be no need to notify anything. Or do you mean that instead of the "full" table, it just requires one match (where `try-completion' is used)? It may reduce the amount of computation performed by the backend function, but not always by much. From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 05:38: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: To: Dmitry Gutov Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138630822620855 (code B ref 11906); Fri, 06 Dec 2013 05:38:02 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 05:37:06 +0000 Received: from localhost ([127.0.0.1]:32813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Voo65-0005QA-D0 for submit@debbugs.gnu.org; Fri, 06 Dec 2013 00:37:05 -0500 Received: from mail-pb0-f48.google.com ([209.85.160.48]:36616) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Voo63-0005Op-02 for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 00:37:03 -0500 Received: by mail-pb0-f48.google.com with SMTP id md12so421835pbc.7 for <11906@debbugs.gnu.org>; Thu, 05 Dec 2013 21:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=sG2xjA+fAz3uMwVx/rLS+YWY1XHb02HI451VJyZ68e4=; b=q+yCEO9OCVcj2W2mfycGTnJKUCtOHakE9A19QLrk9UMisrZTMCn3Ey0Vrzan0IahLI Rj7DryfY/o72ZMlUEnx87Hq8/gq2JYl0a5YzoC1zIqMr85uIk2Tgk/Bg90bnNr3vsH7R cTYZBStRpWu1vAqM/8kWwSxMCO356aZV2TNowrGZKQKp0nrY8x0+yTJMmWgsIn+OPdna GaCWPNEWdS/pHahPPrvlPbhkDiVV25dWlgjeSDtIVD0vjB55VU4DVgVojyi/KGFJLV7l 1Vwu54QplyTrqjlOFPKGhi57ikSFEhBEectNIggIYdGOWHQZPBi5NSWlSEtuf5P+ABe4 FAKQ== X-Received: by 10.66.231.72 with SMTP id te8mr1930174pac.11.1386308221878; Thu, 05 Dec 2013 21:37:01 -0800 (PST) Received: from localhost ([123.119.93.169]) by mx.google.com with ESMTPSA id qz9sm147578611pbc.3.2013.12.05.21.36.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2013 21:37:01 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACkAAAApAQAAAACAGz1bAAABKElEQVQYlWNg3NIt5FDPUPt7 4+X79Qyucz5/ugik+L2PBgKpyphaIK921q23QDnG0NBQoMr/vaWl9f8ZLL78uPv5PwN7RETfzXoG jhmFz27XM0RXmpuY/WfY+fv0Mc56BvFybfXA/wwL5t/wF61n2PU59axXPcOVzbmSW/8zrNt1benC /ww70hqUU/4zKCtrT9jwn8FhwynbufUMendE2aLqGRpdX9al1zM8eh17lKeeQcTMrdD5P8P3j/YT Q/8zXHSb7p1Qz/C4OM2JuZ7hgtI7K6AjqsMnf8j4z8C6xG1tw3+GqpqvsVn/GTzmpD9j/8/wP/oZ S/l/Bka+QO/g/wy15ueeFQL9N1O8mPU/g+umV3t1gdT0/1bTgHLqYVeXAlWKpMWt+w8Az82C9nHf X0cAAAAASUVORK5CYII= Date: Fri, 06 Dec 2013 13:36:52 +0800 In-Reply-To: <52A1534D.3000902@yandex.ru> (Dmitry Gutov's message of "Fri, 06 Dec 2013 06:32:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2013-12-06 12:32 +0800, Dmitry Gutov wrote: > I don't understand what you mean by "doesn't need a completion table". > Could you give an example? See completion-at-point: (let ((newstart (car-safe (funcall hookfun)))) (and newstart (= newstart start))) so basically every command following completion-at-point calls HOOKFUN to check if start matches, in this case it doesn't need the completion table. Hopefully There will be more places to optimise if studying minibuffer.el in more details. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 13:16: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13863357164584 (code B ref 11906); Fri, 06 Dec 2013 13:16:02 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 13:15:16 +0000 Received: from localhost ([127.0.0.1]:33366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VovFT-0001Bs-SL for submit@debbugs.gnu.org; Fri, 06 Dec 2013 08:15:16 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:55582) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VovFS-0001Bk-94 for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 08:15:14 -0500 Received: by mail-wi0-f180.google.com with SMTP id hn9so795061wib.1 for <11906@debbugs.gnu.org>; Fri, 06 Dec 2013 05:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=T3BeSgosCH5UKXwsWg2Oo7BFTlgQk5dopvefZ3qSuHU=; b=ex3S+5XYY0UDML4mUt8qcaMiElnhf5EYf/2GDsGwD7gNaG+OdmALrkv5s+XlSoG/Zn vntD8dVCOHow5EQdKN7f9SIhZMVGJm48wSG+F9wjN1n7gJpSWQp9KmkPYPdDERUdQcp6 gwUmr0JwTqCcanM+6ySvywBn2sBvqywoz9H4Acycwy7krsCXVGF3ncSMtJ3TaxHjGLHU mjOTrTs/RJu1OhfY9xqIcAid8mkBi28ldeIXF4l+W8Wl+GXoB4L+fYccvjQG+A+EB26X CONUcxzAe00MDyWNqFTA6R0sK27HeRKpZgWivzFwmP6oQQVMb2rPQXA/J4C1ZjG/C6g5 6/9Q== X-Received: by 10.194.84.72 with SMTP id w8mr22074922wjy.55.1386335713306; Fri, 06 Dec 2013 05:15:13 -0800 (PST) Received: from [192.168.10.48] (93-245-142.netrun.cytanet.com.cy. [93.109.245.142]) by mx.google.com with ESMTPSA id d2sm6114423wik.11.2013.12.06.05.15.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 05:15:12 -0800 (PST) Message-ID: <52A1CDDD.1050808@yandex.ru> Date: Fri, 06 Dec 2013 15:15:09 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 06.12.2013 07:36, Leo Liu wrote: > See completion-at-point: > > (let ((newstart (car-safe (funcall hookfun)))) > (and newstart (= newstart start))) > > so basically every command following completion-at-point calls HOOKFUN > to check if start matches, in this case it doesn't need the completion > table. But that function is fast! Compared to doing the actual completion, the time it takes to `(funcall hookfun)' should be negligible: ELISP> (js2-time (setq ocap (with-current-buffer "*Inferior Octave*" (octave-completion-at-point)))) 0.0 ELISP> (js2-time (with-current-buffer "*Inferior Octave*" (funcall (nth 2 ocap) "a" nil t))) 0.0055 From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 14:05: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: To: Dmitry Gutov Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13863386939339 (code B ref 11906); Fri, 06 Dec 2013 14:05:02 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 14:04:53 +0000 Received: from localhost ([127.0.0.1]:33419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vow1U-0002QY-Vz for submit@debbugs.gnu.org; Fri, 06 Dec 2013 09:04:53 -0500 Received: from mail-pd0-f173.google.com ([209.85.192.173]:39563) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vow1S-0002QP-2A for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 09:04:50 -0500 Received: by mail-pd0-f173.google.com with SMTP id p10so1068398pdj.4 for <11906@debbugs.gnu.org>; Fri, 06 Dec 2013 06:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=70NzcBkCBCWS/rQwAVncjEfFROCs0zmWU7AOdlAjy0U=; b=k0JDIragSposCbk1RoFcor8kvqvd0CYqJJIldHjV32ir6b4awCCnjYU5Z699PnocXM pUIq+Sg+XunasgPcu31NWgOPXTcC+n2qX4KU8JowvX1hLRakao6+FlkNAYAsHJbf63/m QqeTDGCAEVoE6Dd7/dHBKz5OoRFnvQw45qo005GnW5nIgNx30/xekUrANYrdkbahQ9zS P6XB05jbZOkjzIa2/AW2ifC5N4/7xiNqzKLWjWndnNXODwMPTj7/2LoJKKgtMgbQ1uyR 5xjK5CJk2k6guOpcSx/IFTZHDk8PGrQoCJUUV8yIFw6MTKPzujhrfT28zcRuFmz+JuGy H0lA== X-Received: by 10.66.136.71 with SMTP id py7mr4296498pab.2.1386338688817; Fri, 06 Dec 2013 06:04:48 -0800 (PST) Received: from localhost ([123.119.93.169]) by mx.google.com with ESMTPSA id jk16sm41780806pbb.34.2013.12.06.06.04.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2013 06:04:47 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoAgMAAADxkFD+AAAADFBMVEUvT09qWs3/pQD///+J kUVcAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMLOd3veKQA AACuSURBVBjTldE9CgIxEAXgB+lEyFUC2wo5ikdZ8DSypxhMY7H9VuIVwlqkGRgnm59VsHGafIQ3 CZlAtmKIRaHETgYa12lqvEsPYKf8wXHsPGfqPaUM0g9aJPKFXkmNQmSDqwzz4Fpgpz+6WAPY2z5o uPJJpu0uypcl4nyCibMLQ8lCiVjayLoQvw5LsVKQuHPRR958HZbOcVsKeepcLxpByjycGvnKmY+c MBvrtyjfe0vmuLvdq/kAAAAASUVORK5CYII= Date: Fri, 06 Dec 2013 22:04:43 +0800 In-Reply-To: <52A1CDDD.1050808@yandex.ru> (Dmitry Gutov's message of "Fri, 06 Dec 2013 15:15:09 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) On 2013-12-06 21:15 +0800, Dmitry Gutov wrote: > But that function is fast! Compared to doing the actual completion, > the time it takes to `(funcall hookfun)' should be negligible: > > ELISP> (js2-time (setq ocap (with-current-buffer "*Inferior Octave*" > (octave-completion-at-point)))) > 0.0 > ELISP> (js2-time (with-current-buffer "*Inferior Octave*" (funcall > (nth 2 ocap) "a" nil t))) > 0.0055 I see. Let's consider the performance issue fixed for now. Another issue as mentioned in the report is when you complete, for example, 'abc' to 'aa bb cc' (or whatever strange chars are in the completion candidate) and the completion function fails to go back to the start. Can this be improved? On a case to base basis the completion function could use a marker so that it can subsequently find the starting point. But can minibuffer.el handle this so that all completion function don't need to worry about this? Also instead of calling completion function to check if start has changed to decide to exit completion-in-region-mode, how about let any char insertion or deletion exit the mode instead? Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 17:36: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: To: Leo Liu Cc: 11906@debbugs.gnu.org, Dmitry Gutov Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13863513342755 (code B ref 11906); Fri, 06 Dec 2013 17:36:02 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 17:35:34 +0000 Received: from localhost ([127.0.0.1]:34451 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VozJO-0000iM-92 for submit@debbugs.gnu.org; Fri, 06 Dec 2013 12:35:34 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:44377) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VozJM-0000iF-F4 for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 12:35:32 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 1CB6084D93; Fri, 6 Dec 2013 12:35:32 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 946041E5B8A; Fri, 6 Dec 2013 12:35:07 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 7A297B40FA; Fri, 6 Dec 2013 12:35:07 -0500 (EST) From: Stefan Monnier Message-ID: References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> Date: Fri, 06 Dec 2013 12:35:07 -0500 In-Reply-To: (Leo Liu's message of "Fri, 06 Dec 2013 22:04:43 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) > Another issue as mentioned in the report is when you complete, for > example, 'abc' to 'aa bb cc' (or whatever strange chars are in the > completion candidate) and the completion function fails to go back to > the start. This would be a bug (probably in the completion-at-point-function). > Can this be improved? On a case to base basis the completion function > could use a marker so that it can subsequently find the starting point. That should "never" be necessary. Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Dec 2013 17:37:01 +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: To: Leo Liu Cc: 11906@debbugs.gnu.org, Dmitry Gutov Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13863514112893 (code B ref 11906); Fri, 06 Dec 2013 17:37:01 +0000 Received: (at 11906) by debbugs.gnu.org; 6 Dec 2013 17:36:51 +0000 Received: from localhost ([127.0.0.1]:34456 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VozKc-0000kb-Nc for submit@debbugs.gnu.org; Fri, 06 Dec 2013 12:36:50 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:49301) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VozKb-0000kU-8X for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 12:36:49 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 02EE384593; Fri, 6 Dec 2013 12:36:49 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 5D8F31E5B74; Fri, 6 Dec 2013 12:36:25 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 4F30FB40FA; Fri, 6 Dec 2013 12:36:25 -0500 (EST) From: Stefan Monnier Message-ID: References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> Date: Fri, 06 Dec 2013 12:36:25 -0500 In-Reply-To: (Leo Liu's message of "Fri, 06 Dec 2013 22:04:43 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.5 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.5 (--) > Also instead of calling completion function to check if start has > changed to decide to exit completion-in-region-mode, how about let any > char insertion or deletion exit the mode instead? There's no technical reason not to, but... why would we want to do that? Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2013 02:03: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: To: Leo Liu Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138638175128093 (code B ref 11906); Sat, 07 Dec 2013 02:03:02 +0000 Received: (at 11906) by debbugs.gnu.org; 7 Dec 2013 02:02:31 +0000 Received: from localhost ([127.0.0.1]:35188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7Dy-0007J3-Q0 for submit@debbugs.gnu.org; Fri, 06 Dec 2013 21:02:31 -0500 Received: from mail-ee0-f53.google.com ([74.125.83.53]:63638) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7Dw-0007Is-Lp for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 21:02:29 -0500 Received: by mail-ee0-f53.google.com with SMTP id b57so592841eek.12 for <11906@debbugs.gnu.org>; Fri, 06 Dec 2013 18:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rbQ+iyBjm5OElrYsXL6FOP81t2vxMnwVvzhtRWQbhqM=; b=z8mV7Z+sFu+LIdjVugBRzjKqnL2RBAZWG2bC76bodU1A3WZZNjI4BWtHmog/4zJ+kz WPB1Qm7V/8FTTtBoqrLjPjwKeIgfHanAsG2MRFfGjXsW8iWGSq0eWJAC5K9//izJYJEf rQQsLBDP639MZIBhjCXiJZopU3/Bmn0IzZXhKvnUHEYxWYtR+d/Q5TNfAEZJ3q/ESMZk bJXZu+qyzB4s/vMWYtCmNP8E5Z/kny/RXI4jmqycMCInalEkx4+mypK6T9lVRLrImGWK PAR43hULAixPnGhF5+6/InchalV7VmwsNnDWH3zCU053iuteB3rcjBHWuQErHq9Fa9Tm JMUg== X-Received: by 10.14.205.201 with SMTP id j49mr5256556eeo.85.1386381747714; Fri, 06 Dec 2013 18:02:27 -0800 (PST) Received: from [192.168.10.2] ([62.228.136.233]) by mx.google.com with ESMTPSA id h48sm1515243eev.3.2013.12.06.18.02.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 18:02:26 -0800 (PST) Message-ID: <52A281AF.5030008@yandex.ru> Date: Sat, 07 Dec 2013 04:02:23 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 06.12.2013 16:04, Leo Liu wrote: > Another issue as mentioned in the report is when you complete, for > example, 'abc' to 'aa bb cc' (or whatever strange chars are in the > completion candidate) and the completion function fails to go back to > the start. It seems to me that `completion-at-point' isn't a good facility to complete space-separated lists of words or symbols (unlike, say, hippie-expand). Suppose it works, and you have candidates: "aa bb cc", "aa bd ee", "aabbc ef". You type "aa", press C-M-i, it completes to the common prefix: "aa b". Even if `completion-at-point' still remembers where the candidate started, what if you exit `completion-in-region-mode' via, say, cursor, movement, and then go back to after "aa b". When you press C-M-i again, what completion candidates would you expect to see? Not "aa bb cc" and "aa bd ee", right? Note that this can be fixed in specific completion-at-point functions. For example, Objective-C completion can look at the context, or maybe just always treat semicolons as symbol constituents (I don't really know the syntax). > Also instead of calling completion function to check if start has > changed to decide to exit completion-in-region-mode, how about let any > char insertion or deletion exit the mode instead? Could be good for some cases and users, but this prohibits the user from looking at the completions buffer and typing one of the candidates, manually (maybe a part of it, until it's unique). Hiding the completions buffer right after one character is typed can make it less useful. From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2013 02:06:01 +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: To: Stefan Monnier Cc: 11906@debbugs.gnu.org, Dmitry Gutov Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138638193728404 (code B ref 11906); Sat, 07 Dec 2013 02:06:01 +0000 Received: (at 11906) by debbugs.gnu.org; 7 Dec 2013 02:05:37 +0000 Received: from localhost ([127.0.0.1]:35195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7Gx-0007O0-Ut for submit@debbugs.gnu.org; Fri, 06 Dec 2013 21:05:36 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:35091) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7Gq-0007Nk-FJ for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 21:05:29 -0500 Received: by mail-pb0-f41.google.com with SMTP id jt11so2075778pbb.14 for <11906@debbugs.gnu.org>; Fri, 06 Dec 2013 18:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=NAdnsMFIj/EMwu02WfQnji9b0Qu2obLie+8Bkgamnyc=; b=UxuuYRvfGoMzvPx4yPXy9/hqhVtaITrKKzcGPBiUpriHlrYCcFLPKR+DGsvsmMbL41 G5M7U69/M4xr3zCdruorGqWDClBrFrEe94WWOMxXCe86LEkc/u92h7ooqS62ND6/z8qs wpYj992nhPaufY99QMZjcRlR9IWKcXUcR2TGp8me9TUkFCcIrcS12l0KkWfQC5hXE25B mqn3SKvKqrFlZW3w+93Y8vndhSJxRdMTxOTe0yAOgO7UP2bGL5amTutz99XnLAxVhtjM Igcn9mnDAJQV8UYEa1YNtQCyM/jlD+T5kwzVZ9tNdAleZkgNRpoUQH8i9I8gTJydi1F4 4SmA== X-Received: by 10.66.121.131 with SMTP id lk3mr7566595pab.61.1386381927445; Fri, 06 Dec 2013 18:05:27 -0800 (PST) Received: from localhost ([123.119.93.169]) by mx.google.com with ESMTPSA id dq3sm690436pbc.35.2013.12.06.18.05.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2013 18:05:26 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAGFBMVEUKDAg1NjRWV1V9fnyg op/DxcLk5uP8/voi63ReAAAACXBIWXMAAAWJAAAFiQFtaJ36AAAAB3RJTUUH1goZAgAz00bgXgAA AeVJREFUKM9lk0Fz2jAQhQXJD3CCO70CmcC1YMtcWyTZ14Bl69xats4N9r6/3zWQBlodNKNPu/s0 b1cCQFuZGpfVVh3vAvBJolIXRkapSuoRUtIdFyo1Y5xSdlAj7OtvD1XnXxmWRi+eWgcxyCed1lVV B1CrKyujMoi+eLA5kU1SsjoHlW+nQjTtFxk4MXgrOxvIqzoTZR8XgPaLl419zgsMaSGFPiUOZCIh thsx5Xy9NsK8Kwf/JoQgMxcVJ301HKkcSWaT0O7FY056J4U9xcYfnmVXG4801lW6lqwu2nKFZoHC HuzvaTVndZ+LaRQgZdthXw1cpynEkLEwyFHXk/aIxNQ6QeooJuzPMB+wn+D7JJNsiCcVA13/A3h/ xE9J+WidpAwoYNmRFwyvSRhNVtsdaAewzZZP5uw82QL9+tyNfocyP0McAzICUr5Mk9RdIjWasUNx aIIt6NK4ZtXIMdfMQt3nuMAyWbLI4DqZ4xPq/ag8jPond4XU/cLuOgw6XCFX/YCUfcDAMMH58fD4 G9kDchwfqVefkBwup2uZM+Q4WhJt5jN3AxXCsaS2yXEDuWgS8VOzW0gFjhEPmLyFMKBFaLb1HRwc DiaKwx0EeTMRYnYPQRW3PP4HApvlMv0PttX5v/D6Aws3IOSEwzmLAAAAAElFTkSuQmCC Date: Sat, 07 Dec 2013 10:05:20 +0800 In-Reply-To: (Stefan Monnier's message of "Fri, 06 Dec 2013 12:35:07 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2013-12-07 01:35 +0800, Stefan Monnier wrote: [snipped 5 lines] > This would be a bug (probably in the completion-at-point-function). [snipped 4 lines] > That should "never" be necessary. On 2013-12-07 01:36 +0800, Stefan Monnier wrote: [snipped 3 lines] > There's no technical reason not to, but... why would we want to do that? [snipped 3 lines] For this case: --8<---------------cut here---------------start------------->8--- Assume three candidates (ObjC selectors) for completion and completion-cycle-threshold is 5: 1. stringWithContentsOfFile: 2. stringWithContentsOfFile:encoding:error: 3. stringWithContentsOfFile:usedEncoding:error: After cycling a few times, I see: [NSString stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$ --8<---------------cut here---------------end--------------->8--- So indeed it is the capf's failure to go back to the proper starting point after the insertion of the first completion candidate. But the capf could have no idea what chars the completion candidates can be made of. In the example it is : that capf needs to handle. sometimes it is SPC or [ or { or whatever. How can this be handled reliably? Thus my proposal to use marker. i.e. in the beginning of a completion session set a start marker. In general the idea is to make the completion machinery in minibuffer.el only have to ask capf for information once for each completion session. Leo From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2013 02: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: To: Dmitry Gutov Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138638404531651 (code B ref 11906); Sat, 07 Dec 2013 02:41:02 +0000 Received: (at 11906) by debbugs.gnu.org; 7 Dec 2013 02:40:45 +0000 Received: from localhost ([127.0.0.1]:35223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7oy-0008EQ-RP for submit@debbugs.gnu.org; Fri, 06 Dec 2013 21:40:45 -0500 Received: from mail-pb0-f45.google.com ([209.85.160.45]:49641) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vp7ov-0008EH-FV for 11906@debbugs.gnu.org; Fri, 06 Dec 2013 21:40:41 -0500 Received: by mail-pb0-f45.google.com with SMTP id rp16so2104646pbb.18 for <11906@debbugs.gnu.org>; Fri, 06 Dec 2013 18:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Myj9FXFw1PzyLmj+7axdvm2IMwqD+rZa0I0ivVqJDmU=; b=KuAuNiJeMXjqqlNgKycxmQdEQKIqSOQnvi2xePZp4TUA31G2FOSowf7W9j5DsXRIas x4emuOHDTPCz/L+HltfhmO/8KwMl00YEG+0l2cf/opEvfg/keasdsHLSuhKVd7gBTXEO 1f8K7l6uASed8SLwGw6cF4p1SKZxR1FWVVodOi4a9kxBBdsond/tQm0d9bSwtYl93hI4 XIZ0hiZpk6pLfawkVGic4hnGqYbnjkFWcoPxudxO7QqSEFcu9Aq0WjUqoQ6qQRc12UVm K66ZUOyxlQRqAk5LM6rjfvqV74AX8SPiX36HlwhKtZuo2mn3IG/7zIzpexLuIhrJ0vel ZUWQ== X-Received: by 10.68.143.231 with SMTP id sh7mr7793450pbb.7.1386384040617; Fri, 06 Dec 2013 18:40:40 -0800 (PST) Received: from localhost ([123.119.93.169]) by mx.google.com with ESMTPSA id lh13sm1356045pab.4.2013.12.06.18.40.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Dec 2013 18:40:40 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> <52A281AF.5030008@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoBAMAAAB+0KVeAAAAElBMVEUAAAAAAP+LRRP0pGC+ vr7///+7mT1iAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMO DhglKe4AAAEsSURBVCjPbZNBboQwDEV/Cd4X9QJRThApmn0XYW+Jyf2v0m+HhqDBgiAe9rcTG7QH w/1Vn2Ar8gBb/ocywSN3qK9T3z4eFDB4eApocBpeBs1RSykoJd8gQcm8pGmHXFso3ajnmsqV0TnY DQkOfXUfN5NwaI7AWTVOyEhcu1aHmdWItHddUVUcUgUBCkitu8V6ditHVOVdqzl2EQ1ZVGTbdK0V 7cqn8vWzoU5Q/bF9Y/Y0cRU1xwkys5dJ+Dt6pBDWifcNQml8Gh2JVmPSoQzo7en0grswkxrUGYJ7 0hSxxAGr7ZMwYcHIzprpi7TENEE1xtiYxixRlCfPBsUUrwHD7uGIwATrbnODJcVrPpVn3hxiGloe m/S+z3CtuzUSMo83N4DPH+F0evwR3P4A2k+75838OKQAAAAASUVORK5CYII= Date: Sat, 07 Dec 2013 10:40:33 +0800 In-Reply-To: <52A281AF.5030008@yandex.ru> (Dmitry Gutov's message of "Sat, 07 Dec 2013 04:02:23 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2013-12-07 10:02 +0800, Dmitry Gutov wrote: > It seems to me that `completion-at-point' isn't a good facility to > complete space-separated lists of words or symbols (unlike, say, > hippie-expand). > > Suppose it works, and you have candidates: "aa bb cc", "aa bd ee", > "aabbc ef". You type "aa", press C-M-i, it completes to the common > prefix: "aa b". Even if `completion-at-point' still remembers where > the candidate started, what if you exit `completion-in-region-mode' > via, say, cursor, movement, and then go back to after "aa b". When you > press C-M-i again, what completion candidates would you expect to see? > Not "aa bb cc" and "aa bd ee", right? > [snipped 9 lines] > Could be good for some cases and users, but this prohibits the user > from looking at the completions buffer and typing one of the > candidates, manually (maybe a part of it, until it's unique). > > Hiding the completions buffer right after one character is typed can > make it less useful. These are good points. I think we need a new way for completion. Thanks for your work and feel free to close this bug. Leo From unknown Tue Jun 17 01:40:56 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Leo Subject: bug#11906: closed (Re: bug#11906: 24.1; completion-at-point failures) Message-ID: References: <52A34930.7080908@yandex.ru> X-Gnu-PR-Message: they-closed 11906 X-Gnu-PR-Package: emacs Reply-To: 11906@debbugs.gnu.org Date: Sat, 07 Dec 2013 16:14:04 +0000 Content-Type: multipart/mixed; boundary="----------=_1386432844-17755-1" This is a multi-part message in MIME format... ------------=_1386432844-17755-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #11906: 24.1; completion-at-point failures which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 11906@debbugs.gnu.org. --=20 11906: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D11906 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1386432844-17755-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 11906-done) by debbugs.gnu.org; 7 Dec 2013 16:13:44 +0000 Received: from localhost ([127.0.0.1]:36678 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpKVk-0004bl-3u for submit@debbugs.gnu.org; Sat, 07 Dec 2013 11:13:44 -0500 Received: from mail-ee0-f52.google.com ([74.125.83.52]:37530) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpKVh-0004bd-LI for 11906-done@debbugs.gnu.org; Sat, 07 Dec 2013 11:13:42 -0500 Received: by mail-ee0-f52.google.com with SMTP id d17so795798eek.11 for <11906-done@debbugs.gnu.org>; Sat, 07 Dec 2013 08:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BSE+JQL4lcTrISi/RoO/XqvVmekpsvS73Q91ZLyHhrA=; b=cBLLx332azYB8LLRSY1CKLnCO32NhYpU/sPkxp9+T22MQ+Px0FsWPhK4zsl1T7DT7O BK73vukgP1DAQTWZM8UOautcIoHEkkT18VlGe2tF9tYVHDhqc6y4SybWMcfnQ0hx71mB U8DtpTAZmvffxJWVVouxjD4y2FGvw6pt95b2EP7VsR+13vzu08Sf16LpMtkPi2vYX3mT 4bC4FJVQ1NTmSGSSZSUM83XSkLAF+PnD+eKCQq5kmOVciUbZ8hS+7c/OsXTwlPpAWZ4P oDC3hzoRGU6WR1Mm6jp/tPeperno6Hgi/lGZtvjyq+yD/1XcXt/sfXi81Org9cE0J5WR fBxw== X-Received: by 10.14.95.8 with SMTP id o8mr162718eef.114.1386432820785; Sat, 07 Dec 2013 08:13:40 -0800 (PST) Received: from [192.168.10.2] ([62.228.136.233]) by mx.google.com with ESMTPSA id e43sm7857538eep.7.2013.12.07.08.13.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 08:13:39 -0800 (PST) Message-ID: <52A34930.7080908@yandex.ru> Date: Sat, 07 Dec 2013 18:13:36 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Leo Liu Subject: Re: bug#11906: 24.1; completion-at-point failures References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> <52A281AF.5030008@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 11906-done Cc: 11906-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 07.12.2013 04:40, Leo Liu wrote: > [snipped 9 lines] I think you skipped the most important practical point - that your initial Object-C example can be made to work properly using the current completion-at-point-functions interface. > These are good points. I think we need a new way for completion. Thanks > for your work and feel free to close this bug. Sure, no problem. ------------=_1386432844-17755-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 11 Jul 2012 05:59:46 +0000 Received: from localhost ([127.0.0.1]:32926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sopxh-0004st-M1 for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:59:45 -0400 Received: from eggs.gnu.org ([208.118.235.92]:54463) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sopxf-0004sl-UK for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:59:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SopsP-0001SH-QN for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:54:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:47496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsP-0001SC-KL for submit@debbugs.gnu.org; Wed, 11 Jul 2012 01:54:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsN-0003Fo-Uf for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SopsM-0001Rt-07 for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:15 -0400 Received: from mail-pb0-f41.google.com ([209.85.160.41]:47404) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SopsL-0001Rc-NU for bug-gnu-emacs@gnu.org; Wed, 11 Jul 2012 01:54:13 -0400 Received: by pbbrp2 with SMTP id rp2so1700654pbb.0 for ; Tue, 10 Jul 2012 22:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:x-debbugs-cc:date:message-id:mime-version :content-type; bh=o2BhljlCH1AU0Z0fodu/Rj3NCxcbbMy7QYpF2fs4+mM=; b=QTpEAcBkRPpZ2bkVO9CO8fS1C4TXCd6Xk3yF4la0lJ3hKKbXAG5amEbm2D0RKEDLH9 guotaEOTWzXDGXp7sdAB0PHjb45AcBPlHX12BT7lPlaQZiVDNb3686pzRdohoYgoC13L 5NTM8rkX/Eo1rLwoh0IYd8k1iz+4KOS+E6FIx8eZWF9zrZSJNPg+U7mXi/LuDdZOLy4m bGfzLq55+n0mXFF/zltGSG4PqcRRoZm/9Nnx+6YC8SyJtsAUCI7EIEgJctg0Rx2u4mPn 8wpY22rDNZHeupfffa0x+wUs2V9sfniz88wk3h2ulJs6TuwGz+vatZLbFtN1EDapQ/94 Ibyw== Received: by 10.68.223.34 with SMTP id qr2mr75204456pbc.10.1341986050488; Tue, 10 Jul 2012 22:54:10 -0700 (PDT) Received: from localhost ([119.255.41.67]) by mx.google.com with ESMTPS id ms1sm1023543pbb.63.2012.07.10.22.54.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jul 2012 22:54:09 -0700 (PDT) From: Leo To: bug-gnu-emacs@gnu.org Subject: 24.1; completion-at-point failures X-Debbugs-CC: Stefan Monnier Date: Wed, 11 Jul 2012 13:54:00 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) Hello Stefan, Despite these critical points, I have witnessed great improvement over completions in earlier versions of Emacs. So thanks. Assume three candidates (ObjC selectors) for completion and completion-cycle-threshold is 5: 1. stringWithContentsOfFile: 2. stringWithContentsOfFile:encoding:error: 3. stringWithContentsOfFile:usedEncoding:error: After cycling a few times, I see: [NSString stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$ i.e. succeeding completion failed to remove previous one before inserting its own, it is, in this case, due to : in the completions. But the problem is general, completion-at-point can be tripped over by chars in the completion candidates. I can imagine it fails too if completion contains spaces. I dug a bit and realised that completion-at-point depended too much on members in completion-at-point-functions. Those functions are called multiple times for each trigger of completion. So it can be extremely slow when the calculation is slow. For example, preparing the completion table in ObjC could take a few seconds for libclang to analyse the source and turn the output into something suitable for consumption in Emacs. It seems completion-at-point should be able to do its entire work after obtaining once the data from those functions. This would free users of completion-at-point-functions from worrying about caching. completion-at-point also invokes those functions in order to decide when to exit. This causes problems illustrated at the beginning of this report and, for example, I have also experienced delay in inserting space, dot, etc following a completion. Leo ------------=_1386432844-17755-1-- From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Dec 2013 22:46: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: To: Leo Liu Cc: 11906@debbugs.gnu.org, Dmitry Gutov Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.138645633222193 (code B ref 11906); Sat, 07 Dec 2013 22:46:02 +0000 Received: (at 11906) by debbugs.gnu.org; 7 Dec 2013 22:45:32 +0000 Received: from localhost ([127.0.0.1]:37091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpQct-0005lt-EW for submit@debbugs.gnu.org; Sat, 07 Dec 2013 17:45:31 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:53773) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpQcq-0005lj-3e for 11906@debbugs.gnu.org; Sat, 07 Dec 2013 17:45:28 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFLd/UW/2dsb2JhbABEvw4Xc4IeAQEEAScvIwULCw4mEhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFLd/UW/2dsb2JhbABEvw4Xc4IeAQEEAScvIwULCw4mEhQYDSSIHgbBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="41407939" Received: from 75-119-245-22.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.22]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Dec 2013 17:45:27 -0500 Received: by pastel.home (Postfix, from userid 20848) id DB70660078; Sat, 7 Dec 2013 17:45:26 -0500 (EST) From: Stefan Monnier Message-ID: References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> Date: Sat, 07 Dec 2013 17:45:26 -0500 In-Reply-To: (Leo Liu's message of "Sat, 07 Dec 2013 10:05:20 +0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > --8<---------------cut here---------------start------------->8--- > Assume three candidates (ObjC selectors) for completion and > completion-cycle-threshold is 5: > 1. stringWithContentsOfFile: > 2. stringWithContentsOfFile:encoding:error: > 3. stringWithContentsOfFile:usedEncoding:error: > After cycling a few times, I see: > [NSString > stringWithContentsOfFile:stringWithContentsOfFile:encoding:error:stringWithContentsOfFile:usedEncodin$ > --8<---------------cut here---------------end--------------->8--- Ah, you're talking cycling, not just completion. Yes, cycling needs special treatment since a full candidate is inserted, after which it may very well be that point is not inside the completion field any more. This said, minibuffer.el already has some special treatment for it, but I guess it doesn't cut it in your case. Can you show a concrete test case (ideally starting from "emacs -Q")? Stefan From unknown Tue Jun 17 01:40:56 2025 X-Loop: help-debbugs@gnu.org Subject: bug#11906: 24.1; completion-at-point failures Resent-From: Leo Liu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Dec 2013 02:28:01 +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: To: Dmitry Gutov Cc: 11906@debbugs.gnu.org Received: via spool by 11906-submit@debbugs.gnu.org id=B11906.13865560662364 (code B ref 11906); Mon, 09 Dec 2013 02:28:01 +0000 Received: (at 11906) by debbugs.gnu.org; 9 Dec 2013 02:27:46 +0000 Received: from localhost ([127.0.0.1]:39084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpqZW-0000c4-8Z for submit@debbugs.gnu.org; Sun, 08 Dec 2013 21:27:46 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:34789) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VpqZT-0000bu-Ua for 11906@debbugs.gnu.org; Sun, 08 Dec 2013 21:27:44 -0500 Received: by mail-pb0-f41.google.com with SMTP id jt11so4481630pbb.0 for <11906@debbugs.gnu.org>; Sun, 08 Dec 2013 18:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:face:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=VApVYyHRFdcc8OX+hESTm/NGaTHe1Rf4ul183qVWUGU=; b=0kaOCBXORSDzTHiGWQzDthEVMP9bV5JANy7/T47RJ1Z3xqw/PxcK9GXCOIKg/jSz0H GPHXGCp6C/FF72rQHDEcbq49C9OXcIl4uYYd10sPVyzPAOBTuXjn3ksfbd5vRWCX0/D5 hxUE03N4e3Ekuo9t4nPUVJyYcCzUUCdBvKHl0xX8ctrBVVWrET9spGspZ8jvdpuXmCVL b2dXrhcBiTej70+PVN0Bj/2GFpVqktZ62XShbxyEa0IufO0aZpzVlMtZWG/u1RKYZbCQ v23JeWYoNBkiZcVpITsnmyPhdH6R4MfOjvo+vCDpVOC7lGIimqnbfAyuWOsOODyF05d/ zoaQ== X-Received: by 10.66.227.104 with SMTP id rz8mr18140321pac.74.1386556062907; Sun, 08 Dec 2013 18:27:42 -0800 (PST) Received: from localhost ([222.130.178.133]) by mx.google.com with ESMTPSA id wd6sm19753906pab.3.2013.12.08.18.27.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Dec 2013 18:27:41 -0800 (PST) From: Leo Liu References: <87li776gym.fsf@yandex.ru> <87pppcasli.fsf@yandex.ru> <52A1221D.90501@yandex.ru> <52A1534D.3000902@yandex.ru> <52A1CDDD.1050808@yandex.ru> <52A281AF.5030008@yandex.ru> <52A34930.7080908@yandex.ru> Face: iVBORw0KGgoAAAANSUhEUgAAACgAAAAoAgMAAADxkFD+AAAADFBMVEUvT09qWs3/pQD///+J kUVcAAAAAWJLR0QAiAUdSAAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9cBBwMLOd3veKQA AACuSURBVBjTldE9CgIxEAXgB+lEyFUC2wo5ikdZ8DSypxhMY7H9VuIVwlqkGRgnm59VsHGafIQ3 CZlAtmKIRaHETgYa12lqvEsPYKf8wXHsPGfqPaUM0g9aJPKFXkmNQmSDqwzz4Fpgpz+6WAPY2z5o uPJJpu0uypcl4nyCibMLQ8lCiVjayLoQvw5LsVKQuHPRR958HZbOcVsKeepcLxpByjycGvnKmY+c MBvrtyjfe0vmuLvdq/kAAAAASUVORK5CYII= Date: Mon, 09 Dec 2013 10:27:35 +0800 In-Reply-To: <52A34930.7080908@yandex.ru> (Dmitry Gutov's message of "Sat, 07 Dec 2013 18:13:36 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (OS X 10.9) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 2013-12-08 00:13 +0800, Dmitry Gutov wrote: > I think you skipped the most important practical point - that your > initial Object-C example can be made to work properly using the > current completion-at-point-functions interface. Not really. I have fixed the specific capf long ago and I knew it could be fixed in that case. And my objective C completer is bit-rotting so I cannot test it. My bug report was hoping to trigger a change in emacs's completion facility. Thanks for the fix, Leo