From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41423: 27.0.91; eshell file completion in tramp dir is slow (3 minutes) [regression on pretest] Date: Tue, 01 Sep 2020 20:31:50 -0400 Message-ID: References: <87mu2d7hka.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15643"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Albinus , rrandresf@gmail.com, Tim Vaughan , 41423@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 02 02:33:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kDGiA-0003xp-2i for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Sep 2020 02:33:14 +0200 Original-Received: from localhost ([::1]:60962 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDGi8-0000ji-KD for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 20:33:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35844) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDGhy-0000iL-Lp for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 20:33:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46138) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kDGhy-0005v2-DN for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 20:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kDGhy-0004LQ-Ao for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 20:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Sep 2020 00:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41423 X-GNU-PR-Package: emacs Original-Received: via spool by 41423-submit@debbugs.gnu.org id=B41423.159900672316632 (code B ref 41423); Wed, 02 Sep 2020 00:33:02 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 2 Sep 2020 00:32:03 +0000 Original-Received: from localhost ([127.0.0.1]:57684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDGh0-0004KB-PU for submit@debbugs.gnu.org; Tue, 01 Sep 2020 20:32:03 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDGgy-0004Jh-ON for 41423@debbugs.gnu.org; Tue, 01 Sep 2020 20:32:01 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 106964409C4; Tue, 1 Sep 2020 20:31:55 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A84BB4409BE; Tue, 1 Sep 2020 20:31:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1599006712; bh=mgYCSNbSGbefDNv51z1nWeB7X3t52UHJw8OnP4CkoG0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=h0UkbG+rAM3sjQN/MrGbttE2Zl+XefppbAV8LsZZNz3HJkh9JjNH5vn8talz9ADkw ufXRRU5xU7azxdLZWzzir22Pue79pM1WW1NJB+2OJ8GlAkW5LGDpKaVR7dUa8D2Iv4 FubuMUnGK0OfyfedL5kCoE4sPsMqNTo3j2gAfYSzljAfZH7VEE5DBKFp8Ihn/3evp6 8QLBo1mV3hLXyD5ncOhrrwnp0OTAxR9IbwvXA2jvS/MxDO+nJK7t3qIfLhJvKOHJIF v5CcALUR5A19vYr/ypa5FpdMd1vxYFydSyqmmSpLflWUjUGcoACsaM+6EgZGalzCe7 ESeYgNBhzPEcQ== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5B0912025D; Tue, 1 Sep 2020 20:31:51 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Tue, 1 Sep 2020 17:40:41 +0200 (CEST)") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186897 Archived-At: >> Since in your example you have 2 commands (TAB and RET), that gives you >> a total of 3. > Hmmm... It seems to me that in this case, we're done after the first call > to pcomplete-completions-at-point, Usually it depends on whether the completion inserts a separator (e.g. a space in the case of Eshell/Pcomplete). Otherwise, point is still placed "within" (tho probably right at the END position) the completion area and hence completion is not considered to be finished. You can refine/tune the completion tables so that completion will considered as finished in more cases, but that wouldn't solve the problem in the general case anyway. >> This design relies on the fact that completion tables can be lazy, so it >> should always be possible to make the completion-at-point-function very >> cheap and harmless, so it's OK to call it repeatedly (or even needlessly). > This is not at all documented AFAICS. Given that it's a crucial aspect for > your design to work, it should be. The lispref says the following: The functions on this hook should generally return quickly, since they may be called very often (e.g., from @code{post-command-hook}). Supplying a function for @var{collection} is strongly recommended if generating the list of completions is an expensive operation. Emacs may internally call functions in @code{completion-at-point-functions} many times, but care about the value of @var{collection} for only some of these calls. By supplying a function for @var{collection}, Emacs can defer generating completions until necessary. You can use @code{completion-table-dynamic} to create a wrapper function: >>> There is no reason to call pcomplete-completions-at-point when RET >>> is pressed. >> If running that function is costly, it's a bug. > It was not before you declared `pcomplete' obsolete and removed > `eshell-pcomplete'. Indeed, making the Pcomplete infrastructure compatible with the standard completion UI introduced some incompatibilities. This was true before `pcomplete` was declared obsolete, tho: it has been true since the introduction of `pcomplete-completions-at-point` (some time around Emacs-24, IIRC). > "Provide standard completion using pcomplete's completion tables. Same as > `pcomplete' but using the standard completion UI." > It's NOT the same as `pcomplete', it relies on different conditions. > All completion functions called by `pcomplete-completions-at-point' should > be checked and possibly changed with this new design. In practice it works fairly well for most cases, but yes some functions needed to be changed, and others remain, obviously. > Given this, why did you declared `pcomplete' obsolete (it would make sense > to have both a simple mechanism for simple cases and a more complex one for > more complex cases), and why did you remove `eshell-pcomplete'? There are several questions in there. I deprecated `pcomplete` and `eshell-pcomplete` because AFAIK they didn't have noticeably fewer bugs than `completion-at-point` any more and neither did they offer any feature available from `completion-at-point`. W.r.t simple mechanism for simple cases, I'm not sure what that would concretely look like in this particular case. Some motivations for `pcomplete-completions-at-point`: - make it possible to remove duplicate code that deals with the UI aspect of completion (i.e. the `pcomplete` command) rather than the core purpose of `pcomplete.el` which is to provide a way to specify which completion table applies where on a command line. - let the `pcomplete` machinery work with the standard UI, which means it can also (mostly) obey `completion-styles`. - let the `pcomplete` machinery work with other UIs such as `company-mode`. I believe this last point is more important now. > Indeed this patch works. Thanks. > But now my question is: whould it not be possible to do this (namely, > returning a lazy completion table) in one of the pcomplete-* functions (in > `pcomplete-completions-at-point' itself, or in `pcomplete-completions', > or...), instead of doing this in the individual functions ultimately called > by `pcomplete-completions-at-point'? IIRC it wasn't really easy/possible, no. E.g. in the patch I sent I think there's a bug in that a leading * should change the START..END returned by `pcomplete-completion-at-point-function` so the `glob-name` computation should be done outside of the `completion-table-dynamic`. It could have been made a bit simpler and cleaner I guess if I had decided to "start over from scratch" and force a rewrite of every pcomplete/ function (basically every such function would have to return the same kind of info as returned by `completion-at-point-functions`). It would not have had any code in common with `pcomplete` any more, other than the underlying design (which I find very clever&elegant). Stefan