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: Fri, 28 Aug 2020 23:15:12 +0000 Message-ID: References: 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="2661"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) To: 41423@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 29 01:16:15 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 1kBnbS-0000bP-Rg for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Aug 2020 01:16:14 +0200 Original-Received: from localhost ([::1]:47816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kBnbR-0005sS-Sy for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 28 Aug 2020 19:16:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kBnbG-0005qZ-3c for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2020 19:16:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36113) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kBnbF-0005gt-QA for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2020 19:16:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kBnbF-0005oS-Ln for bug-gnu-emacs@gnu.org; Fri, 28 Aug 2020 19:16: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: Fri, 28 Aug 2020 23:16: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.159865652422294 (code B ref 41423); Fri, 28 Aug 2020 23:16:01 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 28 Aug 2020 23:15:24 +0000 Original-Received: from localhost ([127.0.0.1]:47659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kBnae-0005nW-1P for submit@debbugs.gnu.org; Fri, 28 Aug 2020 19:15:24 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:49407) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kBnaY-0005nF-W5 for 41423@debbugs.gnu.org; Fri, 28 Aug 2020 19:15: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 07SNFFOl005325 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 28 Aug 2020 23:15:15 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 07SNFEfg024451; Fri, 28 Aug 2020 23:15:14 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:186627 Archived-At: Apparently my previous last note was not the last one ;-) I still don't know how this bug should be fixed (except by using (setq completion-at-point-functions '(pcomplete t))), but here is a more detailed explanation of what is happening, at least how I understand it: 1. TAB calls completion-at-point 2. completion-at-point calls pcomplete-completions-at-point, which calls pcomplete/cd; this completes the directory name 3. completion-at-point let-binds completion-in-region-mode-predicate to a lambda, which contains pcomplete-completion-at-point 4. completion-at-point calls completion-in-region, which adds completion-in-region--postch to post-command-hook 5. post-command-hook calls completion-in-region--postch 6. completion-in-region--postch funcalls completion-in-region-mode-predicate 7. this calls pcomplete-completions-at-point a second time, which again calls pcomplete/cd (and adds a '/' after the directory name (?)) 8. RET is pressed 9. post-command-hook still contains completion-in-region--postch: it is called again 10. completion-in-region--postch funcalls completion-in-region-mode-predicate again 11. this calls pcomplete-completions-at-point a third (!) time 12. at this point pcomplete-completions-at-point considers (for some reason, possibly because the last character of the input is '/' (?)) that it is a command that it must now complete 13. therefore instead of calling pcomplete/cd a third time, pcomplete-completions-at-point now calls eshell-complete-commands-list 14. this loops through all possible command names (on the local or remote host) 15. if all command names had had a common prefix, that prefix would have been inserted now, but this is not the case, so the effect of this loop (apart from a waste of time) is nil The fact that default-directory is remote is not important here, the exact same steps take place when it is local, except that step 15 is executed much faster. At step 15 it is possible to interrupt the loop with C-g. At step 8 it is possible to remove completion-in-region--postch from post-command-hook for example by switching buffers with C-x C-b. Why such a overly complicated mechanism is used, or what should be done to avoid this behavior, is beyond my understanding.