[Top][All Lists]

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

Re: Incrementally updating completion UI - caching issues with Tramp

From: Michael Albinus
Subject: Re: Incrementally updating completion UI - caching issues with Tramp
Date: Sat, 08 May 2021 13:49:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

[I've added the tramp-devel ML to CC, for the archives. Pls keep]

Daniel Mendler <> writes:

> Guten Morgen!

Guten Morgen, Daniel.

> I am working on a set of completion packages which try to work closely
> with the facilities provided by Emacs proper.
> *
> *
> *
> *
> These packages are different than the popular Helm and Ivy packages,
> with which you are probably familiar, since my packages avoid inventing
> their own APIs or backend implementations but use what is provided by
> Emacs (completing-read).

I must confess that I don't use completion packages which are not part
of vanilla Emacs. So can't say anything about; OTOH I'm not biased :-)

> Now I am having a problem in my Vertico package, which is a very simple
> Ivy clone. It does not implement any special casing for remote file
> access and uses the file completion table as given. Internally it works
> very similar to Icomplete.

You've mentioned non-essential in the github thread. I recommend to use
it (let-bind it somewhere to t), because it is designed mainly for
completion packages. It's documentation mentions disturbing password
prompts, but it does also some other optimization in Tramp for file name
completion. Perhaps, It could also of help for your other issue #23.

> The file completion table is queried often by Vertico, basically on
> every keypress. This behavior is required by the implementation of
> completion tables such that the list of current candidates is updated
> correctly.
> This leads to a slowdown when accessing remote files via Tramp
> ( Is there some caching
> facility in Tramp available, such that for example the list of files in
> a given directory is not retrieved/updated every time the directory is
> accessed?
> For example one could assume the following hypothetical code:
> ~~~ elisp
> (let ((tramp-enable-aggressive-caching t))
>   (completing-read "Files: " ...))
> ~~~
> If the variable `tramp-enable-aggressive-caching=t` then already cached
> directories are not reloaded. Maybe such a possibility already exists?
> Ideally the file completion table itself could set such a configuration.
> I must admit I didn't look deeply into the Tramp code, but I am treating
> the file completion table as a blackbox here, since I don't want to
> break the completion table abstraction at the UI level as other
> completion systems do in order to specially optimize the Tramp use case.

Tramp has caching built-in. This is controlled by user option
remote-file-name-inhibit-cache. Per default, file name caches are kept
for 10 seconds, but this can be changed. You shall recommend your users
at least not to set it to t, which would disable (inhibit) Tramp's

Tramp caches the result of the function file-name-all-completions for
that defined period; 10 seconds have been proven to be sufficient. I
don't know which function is used by the Verico package to access Tramp;
if it is another one you might have problems.

As a beginning, I recommend you to check, how Tramp is plugged into
Vertico. For example, you might open a remote connection. Set
tramp-verbose to 10, and try to use Vertico for file name completion,
some few characters. When done, reset tramp-verbose to its previous
value (3, if you haven't touched it). There will be a Tramp debug
buffer, which you might send for analysis.

> Thank you!
> Daniel

Best regards, Michael.

reply via email to

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