tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File path completions: strange speed discrepancy


From: JD Smith
Subject: Re: File path completions: strange speed discrepancy
Date: Sat, 18 Sep 2021 12:05:16 -0400


> On Sep 18, 2021, at 3:39 AM, Michael Albinus <michael.albinus@gmx.de> wrote:
> 
> JD Smith <jdtsmith@gmail.com> writes:
> 
> Hi,
> 
>> I’m trying to debug a very strange issue I’ve encountered when using
>> completion UI’s like vertico, selectrum, and fido to navigate remote
>> file paths with tramp (over SSH).  It also occurs (I believe) during
>> normal tab-driven file completion, but isn’t as obvious there.
>> 
>> Here’s the issue:
>> 
>> When navigating a remote SSH host’s files, starting with find-file
>> from a non-remote buffer (like *scratch*), completion is very slow,
>> with each key event taking ~1/2s or so.  Very strangely, in exactly
>> the same session, indeed with the same (controlmaster’d) SSH
>> connection to the remote, C-x C-f starting from a remote file or dired
>> buffer is very fast — new completions come in almost instantly.
> 
> I've tried it with Emacs 27.2 as provided by Fedora 34, and the builtin
> Tramp 2.4.5.27.2. Starting with
> 
> # /usr/bin/emacs -Q -f fido-mode /ssh:fencepost:
> 
> I can see the problem. However, when the completion is slow, results are
> shown when I navigate with <left> and <right> keys. When I use
> 
> # /usr/bin/emacs -Q /ssh:fencepost:
> 
> (TAB-based completion), I don't see significant differences between
> starting from the *scratch* buffer, or from a remote buffer.
> 
> I don't use completion styles, so I cannot be of further help. Tramp is
> agnostic to completion styles, it provides just the implementation for
> `file-name-completion' and `file-name-all-completions'.
> 
> I propose to write an Emacs bug report.

I appreciate your thoughts and testing, and am glad you could reproduce the 
problem.  Using exactly the same “plain TAB-based” testing setup you proposed 
with my local server on a wired connection, I can still certainly see a 
difference starting from *scratch* vs. a remote buffer.  

To keep things fair, I performed a M-x tramp-cleanup-all-connections between 
tries.  The initial SSH connection time is similar, but completing additional 
file-paths is clearly not.  For example, starting from *scratch* and hitting 
TAB at a directory name (completing the full directory listing) is very clearly 
and noticeably slower than doing so starting from a remote buffer.  Most 
interestingly, as long as you _start_ from any remote buffer, you can even 
change the host, and this time discrepancy still remains!

I do note that with TAB-based completion, it’s a more subtle difference, 
presumably since in standard completion, completion-all-completions is called 
only when [Tab] is pressed, vs. on every keypress.  But the difference is real, 
and clearly noticeable to me.  So I do not believe this has anything to do with 
completion styles, completion UI's, etc.  More aggressive completion front-ends 
like fido-mode simply magnify and make much more obvious the underlying issue.

If you had any thoughts on how I could investigate what might lead to such a 
discrepancy, even with normal TAB-based remote file-path completion, I’d be 
grateful.  Does tramp setup any extra hooks or callbacks when starting from a 
remote buffer, for example?

Thanks, 
JDS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]