> On Sep 21, 2021, at 9:15 AM, Michael Albinus <[email protected]> wrote:
>
> JD Smith <[email protected]> writes:
>
>> One thing I don’t understand is why tramp needs to re-evaluate the
>> standard value of the variable `temporary-file-directory’ at all.
>> That variable doesn’t appear to change on remote hosts, or ever
>> really. What does change is the returned result of the
>> identically-name function `temporary-file-directory’.
>
> Tramp needs a trustworthy value on the local host. There were bug
> reports, that this variable got another value, somewhere else (even
> remote!), which has broken Tramp. That's why I have introduced this
> defsubst.
OK great. In the meantime people can also:
;; Workaround a tramp-MacOS bug that dramatically slows completion
(put 'temporary-file-directory 'standard-value
(list temporary-file-directory))
>> A quick fix for me was simply to (see FIXED timing, below):
>>
>> (defsubst tramp-compat-temporary-file-directory ()
>> "Return name of directory for temporary files.
>> It is the default value of `temporary-file-directory'."
>> temporary-file-directory)
>
> I have fixed this slightly different: I've changed the defsubst to a
> defconst. All callees need to be changed, but that's simple.
>
> Will be available with next Tramp 2.5.1.3, roughly in a week.
Excellent, thank you!
>> I note that this remains an issue in Emacs 28.1 and Tramp v2.5.1.2.
>
> Yes, there are still discrepancies in my tests (I'm running GNU/Linux),
> mainly in tramp-sh-handle-expand-file-name:
I meant only that this darwin-shell-calling behavior hadn’t yet been fixed on
those newer versions, but I anticipate 2.5.1.3 will fix it for v28.1 as well
(for darwin users). People with fast-starting shells (or users of sshx, which
spawns its own /bin/sh) won’t likely notice any real difference (1.5-2x
slowdown is harder to notice than 10-20x slowdown!).
> Running on "/"
>
> read-file-name-default 1 0.866070978
> 0.866070978
> completing-read 1 0.864735142
> 0.864735142
> completion-file-name-table 21 0.7882453620
> 0.0375354934
> ...
>
> Running on "/ssh::"
>
> read-file-name-default 1 6.540671391
> 6.540671391
> tramp-sh-handle-expand-file-name 408 4.9722099110
> 0.0121867889
> completing-read 1 1.586810819
> 1.586810819
> completion-file-name-table 21 1.3919740299
> 0.0662844776
> ...
>
> So there is still something to be investigated in
> tramp-sh-handle-expand-file-name. But since this is the test case we have
> started on a remote default-directory, it might be OK. At least the time
> for tramp-sh-handle-expand-file-name is not cumulated in
> completing-read. Will see.
This is indeed strange, and oddly the reverse discrepancy of what I found (for
me: remote was fast, local was slow).
I’m not sure if it’s related, but I did discover one additional curiosity:
(getenv “TMPDIR”) returns the same value as getconf DARWIN_USER_TEMP_DIR, so on
Mac the defsubst shouldn’t ever call out to a shell. Debugging this somewhat,
I see that some of the time during tramp-sh-handle-expand-file-name, (getenv
“TMPDIR”) returns nil. Is this expected? I.e. does tramp alter or clear the
environment during some of its call paths? I still think the defconst is a
good fix, since there’s no need even to “getenv” something that is constant.
But the "disappearing environment” may represent a deeper bug, perhaps related
to your remaining issue.
I’ll give 2.5.1.3 a test; let me know if you have a release candidate I can
try.
Best,
JDS
