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: Wed, 02 Sep 2020 10:26:41 +0000 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="20873"; 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 Wed Sep 02 12:27:12 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 1kDPyx-0005H3-W4 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Sep 2020 12:27:12 +0200 Original-Received: from localhost ([::1]:46008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDPyx-00056a-1H for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Sep 2020 06:27:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDPyo-00055V-1Y for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2020 06:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46881) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kDPyn-00047g-OW for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2020 06:27:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kDPyn-0008EB-Ig for bug-gnu-emacs@gnu.org; Wed, 02 Sep 2020 06:27: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: Wed, 02 Sep 2020 10:27: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.159904241731616 (code B ref 41423); Wed, 02 Sep 2020 10:27:01 +0000 Original-Received: (at 41423) by debbugs.gnu.org; 2 Sep 2020 10:26:57 +0000 Original-Received: from localhost ([127.0.0.1]:58427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDPyj-0008Ds-7S for submit@debbugs.gnu.org; Wed, 02 Sep 2020 06:26:57 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:54848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kDPyb-0008De-MQ for 41423@debbugs.gnu.org; Wed, 02 Sep 2020 06:26:52 -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 082AQlVi020011 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 2 Sep 2020 10:26:47 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 082AQrgW028698; Wed, 2 Sep 2020 10:26:53 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:186922 Archived-At: Hi Stefan, Thank you very much for your detailed answer! > >>> 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: > I see, thanks for the pointer. I did not find this because I was searching for `pcomplete-completions-at-point' and `pcomplete-completions'. It would make sense to put this pointer in pcomplete.el. > > W.r.t simple mechanism for simple cases, I'm not sure what that would > concretely look like in this particular case. > In this particular case, in Emacs 24-26, `eshell-pcomplete' called `pcomplete', which did the completion without triggering the machinery of `pcomplete-completion-at-point', that is, without entering a transient `completion-in-region-mode', without modifying `post-command-hook', and so forth. In particular, `pcomplete/cd' was called a single time. It seems to me (even now that I understand the design of `pcomplete-completion-at-point', and that I understand how the more complex mechanism can be made as efficient as the simple one) that this simple mechanism is often sufficient, that it is easier to understand, and that it should remain available. OTOH I also understand the point that you want to avoid duplicating code. > > 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. > I see. This makes perfect sense, thanks for the clarification. What is still missing IMO is a general description/documentation of the various parts of the completion mechanisms (completion-at-point, completion-in-region, pcomplete, pcomplete-completion-at-point, comint-completion-at-point, icomplete, ...) in Emacs behave and interact. I was completely lost when I started working on this bug, things are a bit clearer now, but still not very clear. > >> Indeed this patch works. > > Thanks. > [...] > > 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`. > *sigh* So this bug can still not be considered fixed?