Don't resolve symlinks in path
Opened this issue · 21 comments
Resolving symlinks is causing doom-mode line to display a ridiculous path for a file that lives in my home directory.
Well, I have to say it's as designed. You need this config.
(setq find-file-visit-truename t)If the file is controlled by vc, refer to vc-follow-symlinks, please.
Thank you for the help!
I realize that this issue was closed and that the solution find-file-vist-truename worked for OP, but I do not want to change the behavior of my editor to fix the path in the modeline. Nearly every file I use is a symlink to a NFS so my modeline has become very long and cluttered. I want to visit the symlink and not the true path. I have a hacked the code in my doom-modeline repo to fix this, but I was wondering if you would be open to making this an optional feature that could be disabled to restore a saner path. I could put together a PR if that would be helpful.
@CeleritasCelery Well, thank you for the comments. Can you please share your codes? PR is always welcome as long as it makes sense. I need to think over it and any ideas are also welcome.
@CeleritasCelery Thanks for sharing!
But I don't think it's the solution. The change may impact other scenarios. If you just want to visit the symlink while not the true files, why should show file true name in modeline? It doesn't make sense. My suggestion is change find-file-visit-truename or use buffer-name style, or manage the file via vcs.
More thoughts?
If you visit the true name it changes your default-directory. If I navigate to a file and chase it through a symlink with find-file-visit-true-name I can no longer go back up a directory to where I was before. I may visit a file that has other files in the same directory, but since it is a symlink, when I open dired or find-file all those files are gone and I have to try and get back to the original directory.
The whole point of symlinks is to have a pointer to a remote file but have it act as though is is integrated into your file system. visiting the true name breaks that utility.
I fully agree with what @CeleritasCelery has to say above. I marked this as resolved as it was partially resolved with the above. It shortened my path a little, but it's still a mess. Again the point of having symlinks for me is to shorten a long path. Not resolve it. Also using them with a NFS share.
Can you try this on your env?
(defun doom-modeline-buffer-file-name ()
"Propertized variable `buffer-file-name' based on `doom-modeline-buffer-file-name-style'."
(let* ((buffer-file-name (file-local-name (or (buffer-file-name (buffer-base-buffer)) "")))
(buffer-file-truename (file-local-name (or buffer-file-truename (file-truename buffer-file-name) "")))
(buffer-file-name (expand-file-name buffer-file-truename)))
(propertize
(pcase doom-modeline-buffer-file-name-style
(`truncate-upto-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink))
(`truncate-from-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename nil 'shrink))
(`truncate-with-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink 'shink 'hide))
(`truncate-except-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink 'shink))
(`truncate-upto-root
(doom-modeline--buffer-file-name-truncate buffer-file-name buffer-file-truename))
(`truncate-all
(doom-modeline--buffer-file-name-truncate buffer-file-name buffer-file-truename t))
(`relative-to-project
(doom-modeline--buffer-file-name-relative buffer-file-name buffer-file-truename))
(`relative-from-project
(doom-modeline--buffer-file-name-relative buffer-file-name buffer-file-truename 'include-project))
(style
(propertize
(pcase style
(`file-name (file-name-nondirectory buffer-file-name))
(`buffer-name (buffer-name)))
'face
(let ((face (or (and (buffer-modified-p)
'doom-modeline-buffer-modified)
(and (doom-modeline--active)
'doom-modeline-buffer-file))))
(when face `(:inherit ,face))))))
'help-echo (concat buffer-file-truename
(unless (string= (file-name-nondirectory buffer-file-truename)
(buffer-name))
(concat "\n" (buffer-name)))
"\nmouse-1: Previous buffer\nmouse-3: Next buffer")
'local-map mode-line-buffer-identification-keymap)))That did not make any difference for me. However this code worked
(defun doom-modeline-buffer-file-name ()
"Propertized variable `buffer-file-name' based on `doom-modeline-buffer-file-name-style'."
(let* ((buffer-file-name (file-local-name (or (buffer-file-name (buffer-base-buffer)) "")))
(buffer-file-truename buffer-file-name))
(propertize
(pcase doom-modeline-buffer-file-name-style
(`truncate-upto-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink))
(`truncate-from-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename nil 'shrink))
(`truncate-with-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink 'shink 'hide))
(`truncate-except-project
(doom-modeline--buffer-file-name buffer-file-name buffer-file-truename 'shrink 'shink))
(`truncate-upto-root
(doom-modeline--buffer-file-name-truncate buffer-file-name buffer-file-truename))
(`truncate-all
(doom-modeline--buffer-file-name-truncate buffer-file-name buffer-file-truename t))
(`relative-to-project
(doom-modeline--buffer-file-name-relative buffer-file-name buffer-file-truename))
(`relative-from-project
(doom-modeline--buffer-file-name-relative buffer-file-name buffer-file-truename 'include-project))
(style
(propertize
(pcase style
(`file-name (file-name-nondirectory buffer-file-name))
(`buffer-name (buffer-name)))
'face
(let ((face (or (and (buffer-modified-p)
'doom-modeline-buffer-modified)
(and (doom-modeline--active)
'doom-modeline-buffer-file))))
(when face `(:inherit ,face))))))
'help-echo (concat buffer-file-truename
(unless (string= (file-name-nondirectory buffer-file-truename)
(buffer-name))
(concat "\n" (buffer-name)))
"\nmouse-1: Previous buffer\nmouse-3: Next buffer")
'local-map mode-line-buffer-identification-keymap)))Hmm, but that codes do not make sense to me 😢
I'm curious whether the issue exists for the local symlinks? In my env, it looks right.
Which style are you using? Can you try truncate-upto-project style with the latest version?
I put @seagle0128 's code into my config.org after I loaded doom-mode line in my config and this is what my bar looks like currently.
config.org is in in ~/org/config.org and the ~org dir is a symlink to ~/dev/active/dotfiles/emacs/.emacs.d/ which I manage with gnu stow.
I'm also on Freebsd which has /home sym linked to /usr/home in the base system. So theirs a lot going on there.
@gregf how about using the latest version without any changes? what does it look like?
On doom-modeline-20190107.1829 form melpa
This is how I have doom-modeline configured btw.
(use-package doom-modeline
:ensure t
:defer t
:config
(setq column-number-mode t)
(setq doom-modeline-major-mode-icon t)
:hook (after-init . doom-modeline-init))
I realize that I did not start emacs, so perhaps the reason mine did change would be because the cached root value was unchanged.
@seagle0128 one thing I want to point out about the code snippet you provided, is that although it makes the path look much cleaner, it is still using the truename, which does not match the default-directory or buffer-file-name and is therefore less useful.
@CeleritasCelery Can you provide the detailed steps to reproduce your issue? I could't reproduce in my env. I need more info, e.g. which style of doom-modeline-buffer-file-name-style, version of doom-modeline, directory and symlinks information, etc.
In #51 (comment), you can see all look fine in my env.
Is that a symlink in your example?
Of course. test.txt is a Sumlin. I also tried with directory symlinks.
I think this issue has been resolved.