On 2023-08-26 07:27:22 -0400, brian via Development of GNU Guix and the GNU System distribution. wrote: > Csepp writes: > > > The docs contain this recommended Emacs setting: > > > > @lisp > > ;; @r{Assuming the Guix checkout is in ~/src/guix.} > > (with-eval-after-load 'geiser-guile > > (add-to-list 'geiser-guile-load-path "~/src/guix")) > > @end lisp > > > > I haven't been using it for a while because I remember it causing > > trouble whenever I was working on other Guile projects. I have been > > running Emacs inside ./pre-inst-env instead, which seems to work just as > > well, if not better. > > > > I'd like to make an amendment to the relevant docs, but would welcome > > some info on why it was originally written this way, maybe there are use > > cases I'm missing. > > I agree that it's bad advice, since it assumes the only reason to use > Guile is to hack on Guix. I also think it's not necessary, since > ‘.dir-locals.el’ in the Guix root should be taking care of this for you > already. I don't use the manual addition to ‘load-path’ you quote above, > and Geiser seems to work fine (within the bounds of Geiser's definition > of “fine”, anyway). Geiser seems to add the project root (I assume based on the git) into the load path automatically. geiser-repl-current-project-function seems to be set by default, and rest is described in the docs: (geiser)Customization and tips, Init files and load paths. Maybe it once was necessary to set this, I am not sure it still is the case. I also use (setq geiser-repl-per-project-p t) and everything seems to just work out of the box. > > The downside of using dir-locals is that Emacs yells quite loudly about unsafe > variables being set. In emacs 29 it should be possible to whitelist it, so it will stop being so annoying. > Another option may be direnv or bufenv? I haven't tried them myself, but have > heard good things. > > -bjc > W. -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.