Hello Miguel! Miguel Ángel Arruga Vivas <[email protected]> writes:
> Hi! > > I think that geiser should use something (project.el, wink wink) to fill > load-path automatically when that's possible. Nevertheless, I have some > comments for this. > > Maxim Cournoyer <[email protected]> writes: >> + >> + ;; Emacs-Guix >> + (eval . (setq guix-directory >> + (locate-dominating-file default-directory >> ".dir-locals.el"))) >> + >> + ;; Geiser >> + ;; This allows automatically setting the `geiser-guile-load-path' >> + ;; variable when using various Guix checkouts (e.g., via git >> worktrees). >> + ;; The checkout root directory name should be prefixed by "guix" for it >> + ;; to work correctly. >> + (eval . (let* ((root-dir (expand-file-name >> + (locate-dominating-file >> + default-directory ".dir-locals.el"))) >> + ;; Workaround for bug https://issues.guix.gnu.org/43818. >> + (root-dir* (if (string-suffix-p "/" root-dir) >> + (substring root-dir 0 -1) >> + root-dir)) > > This is already implemented by directory-file-name. Neat! >> + (clean-geiser-guile-load-path >> + (seq-remove (lambda (x) >> + (string-match "/guix" x)) >> + geiser-guile-load-path))) > > This fails if geiser-guile-load-path does not exist (void-variable). > The cleanup removes other guixes, isn't it? I suggest making the > variable buffer-local and forget about hard-coded names. :-) That's a good suggestion! I toyed with it and it's a bit tricky but I think the v2 patch I'll send as a follow-up does the trick. My concern was also supporting when a user has previously set geiser-guile-load-path in their .emacs init file, e.g.: --8<---------------cut here---------------start------------->8--- (setq geiser-guile-load-path (list (expand-file-name "~/src/guix") (expand-file-name "~/src/shepherd"))) --8<---------------cut here---------------end--------------->8--- That would mean their entries don't get cleaned up (it seems this doesn't matter in my latest tests with the v2 patch though!). >> + (setq geiser-guile-load-path + (cons root-dir* >> clean-geiser-guile-load-path)))))) > > This becomes a push with a local variable. Like this: > > (eval . (setq guix-directory > (locate-dominating-file default-directory ".dir-locals.el"))) > (eval . (when (boundp 'geiser-guile-load-path) This check makes it so that if geiser-guile-load-path is not already defined, nothing happens. It is likely that this is the case, as when relying on just Geiser's autoloads, it is not loaded. The user would have to either set explicitly before hand or call (require 'geiser-guile), which we can't rely on. But we can drop this check. > (make-local-variable 'geiser-guile-load-path) (push > (directory-file-name (expand-file-name > (locate-dominating-file default-directory > ".dir-locals.el"))) geiser-guile-load-path)) I ended up using `cl-pushnew' here instead of push, as otherwise repeated entries were accumulated. One thing that worried me was the %load-compiled-path not appearing in the order defined from guile-geiser-load-path, but in my latest tests as mentioned above it didn't matter. Below, the %load-path and %load-compiled-path variables with this patch, when geiser-guile-load-path is predefined with '("/home/maxim/src/shepherd" "/home/maxim/src/guix") from my .emacs file: ;; scheme@(guile-user)> %load-path ;; $2 = ("/home/maxim/src/guix-core-updates" "/gnu/store/...-emacs-geiser-0.12/share/geiser/guile/" "/home/maxim/src/guix" "/home/maxim/src/shepherd" [...]) ;; scheme@(guile-user)> %load-compiled-path ;; $3 = ("/home/maxim/src/shepherd" "/home/maxim/src/guix" "/home/maxim/src/guix-core-updates" [...]) Patch v2 incoming. Thank you, Maxim
