Re: questionable advice about Geiser load path setting

[wolf <wolf@wolfsden.cz>]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

On 2023-08-26 07:27:22 -0400, brian via Development of GNU Guix and the GNU System distribution. wrote:
> Csepp <raingloom@riseup.net> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]