From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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, 1 Sep 2020 10:31:14 +0200 (CEST) Message-ID: References: <87mu2d7hka.fsf@gmx.de> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14421"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Tim Vaughan , rrandresf@gmail.com, Michael Albinus , 41423@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 01 10:32:09 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 1kD1i5-0003bz-EB for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 10:32:09 +0200 Original-Received: from localhost ([::1]:38086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kD1i4-0002QT-5z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Sep 2020 04:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47462) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD1hy-0002QF-3X for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 04:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43287) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kD1hx-0000UW-QO for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 04:32:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kD1hx-0008DG-N7 for bug-gnu-emacs@gnu.org; Tue, 01 Sep 2020 04:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Sep 2020 08:32: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.159894908431525 (code B ref 41423); Tue, 01 Sep 2020 08:32:01 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 1 Sep 2020 08:31:24 +0000 Original-Received: from localhost ([127.0.0.1]:54833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kD1hM-0008CP-8C for submit@debbugs.gnu.org; Tue, 01 Sep 2020 04:31:24 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:63039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kD1hI-0008CE-JH for 41423@debbugs.gnu.org; Tue, 01 Sep 2020 04:31:23 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0818VJ0c000064 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 1 Sep 2020 08:31:19 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0818VRh1003820; Tue, 1 Sep 2020 08:31:27 GMT In-Reply-To: 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:186818 Archived-At: > >> 26. therefore pcomplete-completions does not call pcomplete/cd but >> eshell-complete-commands-list > > I guess this is the culprit > No, see below. > > and this is where the time is spent. > Yes, this is what I said. > > `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. There is no reason to call pcomplete-completions-at-point when RET is pressed. Typing "cd foo/ RET" does not call pcomplete-completions-at-point. Typing "cd foo TAB RET" should only call pcomplete-completions-at-point to add the trailing slash, and should not build a list of all possible commands. > > 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. BTW, when you want to complete a command name, at least you have some characters in the prefix (or if you don't, you expect that listing all candidates will be slow). Typing "cd TAB" works almost instantaneously (and prints "Sole completion"), even on a remote host. Typing "ls TAB" works almost instantaneously, too, even on a remote host. It prints "Complete, but not unique", and pressing TAB again lists the alternate completion candidates. Typing "l TAB" takes (on a remote host) five to ten seconds before printing all completion candidates, but again this is what a user expects. Nobody expects that typing RET, when the completion has already been done, would take three minutes. > > Maybe `tramp-eshell-directory-change` should tell > `eshell-complete-commands-list` to cache the list and also not to bother > checking `file-executable-p`? > That's yet another, separate issue, that is not relevant here. Indeed there are possible improvements in eshell and tramp, but this bug is in the completion mechanism, not in eshell or in tramp.