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 09:04:27 -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="4060"; 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 Tue Sep 01 15:06:11 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 1kD5zH-0000vp-04 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 15:06:11 +0200 Original-Received: from localhost ([::1]:34004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kD5zG-0007jT-2x for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 09:06:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD5yA-00065t-H8 for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 09:05:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43807) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kD5yA-0003jd-5B for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 09:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kD5y9-0006xv-VM for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 09:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2020 13:05:01 +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.159896547726741 (code B ref 41423); Tue, 01 Sep 2020 13:05:01 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 1 Sep 2020 13:04:37 +0000 Original-Received: from localhost ([127.0.0.1]:55353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kD5xl-0006xF-Ik for submit@debbugs.gnu.org; Tue, 01 Sep 2020 09:04:37 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kD5xj-0006x2-SX for 41423@debbugs.gnu.org; Tue, 01 Sep 2020 09:04:36 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3465910022F; Tue, 1 Sep 2020 09:04:30 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 55C7C100019; Tue, 1 Sep 2020 09:04:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598965468; bh=QidgmSLKF0f6mS+hnLKWuHKoRzS+WJOFW29KiUcmC7E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=o5jg89gh2jjZv9n4Swl6E9+vPSywWTMgACVwXX5XEwqo0ly8OLMGNrPkrEATUAtYF dUyAUFCx80VlV+LqvzjL+4hE+Q1vtK1v1Yky0w62/J8rLXmpjYoiu7jvFSro1SoSpo 50Wzzy8DHL8Cjg6IFNEjb+Vrge0JWxWhQ5PJnTF2dqvaNiWRbM7O+70HpE4mGx1dis jeJ4qlaVZE1myaDn4zFYrn1cfx1WkLqJoI2X0hu4W66KiW4GR7v3W/HhKjtKlfe/8T yGzQUe4WRla0lHgJ28bG1cg/NCPnke/XgP7t8PqGWxewWL8dveak1+2OGvNWrus7iW Ayh7JmdNZe45w== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0DD74120314; Tue, 1 Sep 2020 09:04:28 -0400 (EDT) In-Reply-To: (Gregory Heytings's message of "Tue, 1 Sep 2020 10:31:14 +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:186830 Archived-At: >> `eshell-complete-commands-list` eagerly builds the list of possible >> candidates and it takes a while whereas we should here return something >> quickly and cheaply, e.g. by returning a function which will build and >> return this list more lazily when completion is actually performed. > No, the bug is in the completion mechanism, not in eshell. I don't know > exactly (because the mechanism is so complicated) where the completion > functions should be fixed, but it is clear that there is no reason to call > pcomplete-completions-at-point *three* times. The reason why it does so, is that it wants to know when a "completion session" terminates, e.g. to hide the *Completions* buffer or to run the exit-function. So it calls it: - once to do the actual completion. - once per command in post-command-hook to see if we're done. Since in your example you have 2 commands (TAB and RET), that gives you a total of 3. 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). > There is no reason to call pcomplete-completions-at-point when RET > is pressed. If running that function is costly, it's a bug. That's how completion-at-point-functions was designed. If you want to change that design, be my guest, but it likely implies changes to a fair bit of code, including outside Emacs. >> Of course, the slowdown will presumably still be seen when you do actually >> want to complete a command name, so we should probably try and figure out >> more precisely where the slowdown comes from and how to avoid/reduce it. > That's another, separate issue, and it is not relevant here. Agreed. Stefan