The author quickly moves on after finding that expand-file-name is the issue and routes around the problem. The last time we hear from it is when it is patched out. But what is really going on?

The problem is that many parts of Emacs and libraries built on top of them have not been made fully TRAMP aware. There is an abstraction boundary that is being crossed, assumptions are being violated, etc. because all paths are treated equally, despite the fact that most parts of Emacs can identify that a path is remote (or could be remote).

Fixing the underlying issue and providing latency aware variants of commands is not easy (you usually can't just run elisp on a remote machine), but when we get there Emacs will be even more powerful!

Here is an excerpt from some notes I made back in October.

Consider these cases.

I have 10k files that I want to move on a remote server. I have 10k files that I want to move on a local server.

Where do I put the for loop?

I want to put it so that I only have to call ssh once.

Similar issue with using find and subshells. If I have to invoke a subshell there is significant overhead.

Having even a little bit of knowledge about the latency of running a single command, or the knowledge that certain commands commute under loop reordering would make it much easier to produce efficient code, basically

  #+begin_src elisp
  (do-for-values value '(a b c d e f g)
    (please-do-this-on-the-remote #'command value))
  #+end_src

should be rewritten to

  #+begin_src elisp
  (please-do-this-on-the-remote
    (do-for-values value '(a b c d e f g)
      (command value)))
  #+end_src

However, this is only safe if the values are from the local and not the remote and are not functions that are dependent on local state (that doesn't really matter in strict languages though).

The best way to approach this might be to detect and warn before running. Or not, sometimes you do just want to be more efficient, and if you don't want the optimization then disable it some other way. The reason is because sometimes it is much easier to write the latency multiplying version, and the conversion to the latency efficient form is trivial for a computer but extremely easy to screw up for a human being.

EDIT: Hah. I though I recognized Richard's reply. It was to me.