From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Wayne Harris via Users list for the GNU Emacs text editor Newsgroups: gmane.emacs.help Subject: Re: why is my cd command on eshell on Windows so slow? Date: Sat, 17 Apr 2021 05:28:36 -0300 Message-ID: <86a6px5n7v.fsf@protonmail.com> References: <86r1jaqdia.fsf@protonmail.com> <83r1javyvo.fsf@gnu.org> <86sg3qouli.fsf@protonmail.com> <86sg3p6aal.fsf@protonmail.com> Reply-To: Wayne Harris Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2683"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:g3auD6kq58v5qFpalavsLKBc3C0= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 17 10:29:23 2021 Return-path: Envelope-to: geh-help-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 1lXgKQ-0000aq-Rl for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 10:29:22 +0200 Original-Received: from localhost ([::1]:48918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXgKP-0007B5-VV for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 04:29:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXgJt-0007An-4R for help-gnu-emacs@gnu.org; Sat, 17 Apr 2021 04:28:49 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:45246) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXgJr-0002Ms-Jv for help-gnu-emacs@gnu.org; Sat, 17 Apr 2021 04:28:48 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lXgJp-000ASu-HD for help-gnu-emacs@gnu.org; Sat, 17 Apr 2021 10:28:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129016 Archived-At: Wayne Harris via Users list for the GNU Emacs text editor writes: > Stefan Monnier writes: > >>>>> %cd dir/ >>>>> 0.001 secs >>>>> % >> [...] >>> It appears that the delay has nothing to do with Windows or with the >>> cd-command. It seems to be the procedure >>> >>> completion-in-region--postch >> >> Sounds like bug#41423. >> If that's the case, then I suggest you try the code in Emacs's `master` >> where it should be fixed. > > It really sounds like bug#41423, even because the workaround provided by > Gregory Heytings solves the problem, that is, I don't notice any slow > down after applying: > > (add-hook > 'eshell-mode-hook > (function (lambda () > (setq completion-at-point-functions '(pcomplete t))))) > > On the other hand, applying your patch... > > diff --git a/lisp/eshell/em-cmpl.el b/lisp/eshell/em-cmpl.el > index faf749d836..744be525ec 100644 > --- a/lisp/eshell/em-cmpl.el > +++ b/lisp/eshell/em-cmpl.el > @@ -399,16 +399,21 @@ > > (defun eshell-complete-commands-list () > "Generate list of applicable, visible commands." > - (let ((filename (pcomplete-arg)) glob-name) > + ;; Building the commands list can take quite a while, especially over Tramp > + ;; (bug#41423), so do it lazily. > + (let ((glob-name > + ;; When a command is specified using `eshell-explicit-command-char', > + ;; that char is not part of the command and hence not part of what > + ;; we complete. Adjust `pcomplete-stub' accordingly! > + (if (and (> (length pcomplete-stub) 0) > + (eq (aref pcomplete-stub 0) eshell-explicit-command-char)) > + (setq pcomplete-stub (substring pcomplete-stub 1))))) > + (completion-table-dynamic > + (lambda (filename) > (if (file-name-directory filename) > (if eshell-force-execution > (pcomplete-dirs-or-entries nil #'file-readable-p) > (pcomplete-executables)) > - (if (and (> (length filename) 0) > - (eq (aref filename 0) eshell-explicit-command-char)) > - (setq filename (substring filename 1) > - pcomplete-stub filename > - glob-name t)) > (let* ((paths (eshell-get-path)) > (cwd (file-name-as-directory > (expand-file-name default-directory))) > @@ -455,7 +460,7 @@ > (and eshell-show-lisp-alternatives > (null completions))) > (all-completions filename obarray #'functionp)) > - completions))))))) > + completions))))))))) > > (define-obsolete-function-alias 'eshell-pcomplete #'completion-at-point "27.1") > > ...does not make any noticeable change. [...] Sorry! It does make a noticeable change. Your patch seems to solve the problem quite well for me. I believe this is case closed. Thank you for the marvelous patch.