New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doom-module-from-path couldn't handle symbolic links correctly. #7821
Comments
Actually, I think doom-user-dir also needs special handling... |
There must be another way. I'm not keen on supporting this degree of symlinkery madness. Calling In any case, I'll see if I can address this particular issue, but please reconsider that setup. Even if I manage to fix it, I don't intend to ever officially support that degree of symlinkery inside |
In fact, file-truename is called in two places:
Although it seems crazy that every file is a symlink, I think a simpler solution is to replace |
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke `file-truename` of file, keeping symbolic from being converted to a real path. * lisp/doom-modules.el(doom-module-from-path) Replace file-in-directory-p with string-match to determine the module to which the file belongs. Fix: doomemacs#7821
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke `file-truename` of file, keeping symbolic from being converted to a real path. * lisp/doom-modules.el(doom-module-from-path) Replace `file-in-directory-p` with `string-match` to determine the module to which the file belongs. Fix: doomemacs#7821
* lisp/lib/autoloads.el(doom-autoloads--scan) Remove invoke `file-truename` of file, keeping symbolic from being converted to a real path. * lisp/doom-modules.el(doom-module-from-path) Replace `file-in-directory-p` with `string-match` to determine the module to which the file belongs. Fix: doomemacs#7821
I confirm that...
I have searched the issue tracker, documentation, FAQ, Discourse, and Google, in case this issue has already been reported/resolved.
I have read "How to Debug Issues", and will use it to provide as much information about this issue as possible.
The issue can be reproduced on the latest available commit of Doom.
The issue can be reproduced on a stable release of Emacs, such as 27, 28, or 29. (Unstable versions end in .50, .60, or .9x)
Expected behavior
doom-autoloads--scan
correctly handles symbolic links located underdoom-core-dir
.Current behavior
When doom sync calls
doom-autoloads--scan
to generate autoload, it will callfile-truename
to get the true location of the file. When a file is a symbolic link indoom-core-dir
, since the actual file location is not under the doom-core-dir directory, it will not be judged as a core module, resulting in the generatedinit.el
file not containing Contents of this file.doomemacs/lisp/doom-modules.el
Lines 348 to 357 in 5b7d676
Steps to reproduce
make files in doom-core-dir is symbolic links. such as :)
The init.el generated by doom sync does not contain them.
System Information
https://pastebin.com/cA7VhH4x
The text was updated successfully, but these errors were encountered: