questionable advice about Geiser load path setting

questionable advice about Geiser load path setting

[Csepp]

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.

Re: questionable advice about Geiser load path setting

[brian via Development of GNU Guix and the GNU System distribution.]

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).

The downside of using dir-locals is that Emacs yells quite loudly about
unsafe variables being set. Another option may be direnv or bufenv? I
haven't tried them myself, but have heard good things.

-bjc

Re: questionable advice about Geiser load path setting

[Maxim Cournoyer]

Hi,

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.

Perhaps we should simply mention that when allowing the .dir-locals.el
file at the root of the Guix repo to configure your Emacs, it'll take
care of adding its directory to the load path of Geiser?

This is very handy when working with multiple Guix checkouts at the same
time.

-- 
Thanks,
Maxim

Re: questionable advice about Geiser load path setting

[wolf]

[-- 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 --]

Re: questionable advice about Geiser load path setting

[Maxim Cournoyer]

Hello,

wolf <wolf@wolfsden.cz> writes:

[...]

> 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.

I haven't followed up with the latest Geiser features, but if what you
wrote is true, then it would be nice to streamline our .dir-locals.el
and simply set geiser-repl-per-project-p to t (as a directory-local
variable).

Would you like to see if that continues working the same, across
e.g. Git worktrees of Guix checkouts?

-- 
Thanks,
Maxim

Re: questionable advice about Geiser load path setting

[wolf]

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

On 2023-09-04 21:41:44 -0400, Maxim Cournoyer wrote:
> Hello,
> 
> wolf <wolf@wolfsden.cz> writes:
> 
> [...]
> 
> > 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.
> 
> I haven't followed up with the latest Geiser features, but if what you
> wrote is true, then it would be nice to streamline our .dir-locals.el
> and simply set geiser-repl-per-project-p to t (as a directory-local
> variable).
> 
> Would you like to see if that continues working the same, across
> e.g. Git worktrees of Guix checkouts?

Seems to work as one would expect.  My Guix checkout is in /home/wolf/src/guix,
those in /tmp are worktrees.  I pressed C-c C-z in each of these files, a new
REPL was spawned for each of them.  After that I evaluated the snippet to verify
the paths.

/home/wolf/src/guix/gnu/packages/linux.scm:

    (values (car %load-path) (car %load-compiled-path))
    $8 = "/home/wolf/src/guix"
    $9 = "/home/wolf/src/guix"

/tmp/guix-a/gnu/packages/linux.scm:

    (values (car %load-path) (car %load-compiled-path))
    $5 = "/tmp/guix-a"
    $6 = "/tmp/guix-a"

/tmp/guix-b/gnu/packages/linux.scm:

    (values (car %load-path) (car %load-compiled-path))
    $5 = "/tmp/guix-b"
    $6 = "/tmp/guix-b"

C-c C-z in /tmp/guix-b/gnu/packages/abduco.scm reused the already running REPL
for the guix-b.

> 
> -- 
> Thanks,
> Maxim
>

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 --]

Re: questionable advice about Geiser load path setting

[Maxim Cournoyer]

Hi,

I've made the change proposed and tested; then installed as 65dcfb3f
(".dir-locals: Streamline Geiser configuration.").  Let me know if
you encounter any problem.

-- 
Thanks,
Maxim