Eli Zaretskii <e...@gnu.org> writes: > Thanks you. So the problem seems to be symlinks, and specifically > symlinks to directories.
After sending the penultimate email, and before sending the last (which contained the workaround for modifying `dired-font-lock-keywords' buffer-locally) I ran some more tests, and symbolic links to files are also problematic. Specifically, it's the three checks marked by the following comments in `dired-font-lock-keywords' that are problematic: - ";; Broken Symbolic link." - ";; Symbolic link to a directory." - ";; Symbolic link to a non-directory." Only when the three entries corresponding to the above are removed from `dired-font-lock-keywords', does the issue get resolved. Removing some (but not all) of the entries improves matters, but doesn't resolve them completely. Quoting Michael: #+begin_quote It seems to be related to font-locking, indeed. See variable `dired-font-lock-keywords'. It specifies face recognition running basic file oprtations. For example, ";; Broken Symbolic link" calls `file-truename' and `file-exists-p', while "Symbolic link to a directory" and ";; Symbolic link to a non-directory" invoke `file-truename' and `file-directory-p'. I believe it would be helpful to suppress these checks via a user option. And no, the checks shouldn't be suppressed for remote directories in general, on a fast connection they are valuable. #+end_quote > Michael, what does Tramp do specially in these cases that could > explain the slowdown? > >> The above observations seem consistent with Michael's comments above >> regd. font-lock checks for "Broken Symbolink link" and "Symbolic link to >> a directory". > > Michael, what do these checks entail, and why are they so > CPU-expensive and take a lot of time with slow connections? -- Suhail
