geiser-edit-symbol-at-point

geiser-edit-symbol-at-point

[jgart]

Hi,

Does geiser-edit-symbol-at-point work for anyone?

I've never been able to get it to work with the guix codebase...

relevant config I have in my ~/.emacs:

```
(with-eval-after-load 'geiser-guile
  (add-to-list 'geiser-guile-load-path "~/guix"))
```

Re: geiser-edit-symbol-at-point

[jgart]

On Thu, 10 Nov 2022 19:35:27 -0600 jgart <jgart@dismail.de> wrote:

When I run that geiser-edit-symbol-at-point I get the following message:

geiser-completion--symbol-begin: Symbol’s function definition is void: nil [11 times]

Re: geiser-edit-symbol-at-point

[jgart]

On Thu, 10 Nov 2022 19:35:27 -0600 jgart <jgart@dismail.de> wrote:

> (with-eval-after-load 'geiser-guile
>   (add-to-list 'geiser-guile-load-path "~/guix"))

Also, why does geiser want you to set up the load path manually for every project?

I'd like for the experience to be more like a language server/eglot where I
just enter the guile project and xref just works if the mode is turned on.

Why is this not possible with geiser currently?

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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


I don't really have anything helpful to add, except that I believe
geiser doesn't work the way SLIME or LSP does, where there's some
process parsing a project with semantic awareness. Instead it just
launches guile (or some other repl) and parses the prompt string. As far
as I know it is really just sending text back and forth between a
scheme-mode buffer and a runing repl.

The load path has to be set for each project because the guile repl
isn't aware of any project structure that a particular file is a part
of. It is simply going to parse whatever text it's sent within the
context of whatever %load-path it was initialized with. That %load-path
can either be set with the GUILE_LOAD_PATH env variable or by
geiser-guile-load-path which affects how geiser launches guile.

The way I handle this is by making sure that
${HOME}/.config/guix/current/share/guile/site/3.0 is in my
GUILE_LOAD_PATH so that whatever channels I've pulled in the current
profile are included in any guile repl I start. This gets around needing
to have the guix source cloned down somewhere else. When I'm working on
my configuration files, I have a toplevel script which updates the
%load-path:

```
(when (current-filename)
  (add-to-load-path
   (dirname (current-filename))))
```

So when I load that file into the repl with C-c C-l all the subsequent
use-modules work.

On 2022-11-10 19:44, jgart wrote:

> On Thu, 10 Nov 2022 19:35:27 -0600 jgart <jgart@dismail.de> wrote:
>
>> (with-eval-after-load 'geiser-guile
>>   (add-to-list 'geiser-guile-load-path "~/guix"))
>
> Also, why does geiser want you to set up the load path manually for every project?
>
> I'd like for the experience to be more like a language server/eglot where I
> just enter the guile project and xref just works if the mode is turned on.
>
> Why is this not possible with geiser currently?
>
>

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[Olivier Dion via]

On Fri, 11 Nov 2022, Jake Shilling <shilling.jake@gmail.com> wrote:
> I don't really have anything helpful to add, except that I believe
> geiser doesn't work the way SLIME or LSP does, where there's some
> process parsing a project with semantic awareness. Instead it just
> launches guile (or some other repl) and parses the prompt string. As far
> as I know it is really just sending text back and forth between a
> scheme-mode buffer and a runing repl.

Would this kind of tool be more useful than Geiser?  I find that
auto-parsing of the project could really help refactoring stuff and jump
to definition without having to evaluate every module.  The REPL can
stay there for on the fly modification of the program of course, but
perhaps a communication would be necessary between the auto-parser and
the REPL.  What do you think?

-- 
Olivier Dion
oldiob.dev

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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


Personally, I only use scheme for my guix configuration and I dont't
think Geiser is missing anything for that perpose. After all, I want my
dotfiles to always be evaluated within the global guile environment for
my user.

At the same time, I think that having tooling issolate some files from
the global environment is important for any code base that is going to
be distributed to other users. (e.g. I want SLIME/Cider to only think
about modules that are available within the declared dependencies of a
particular project). Of course, containerize a particular project fairly
effectively with direnv or dir-locals.el.

If I were using scheme for anything more serious, I would probably want
something more like SLIME/Cider, but for my use case there's nothing
missing. 

On 2022-11-11 11:17, Olivier Dion wrote:

> On Fri, 11 Nov 2022, Jake Shilling <shilling.jake@gmail.com> wrote:
>> I don't really have anything helpful to add, except that I believe
>> geiser doesn't work the way SLIME or LSP does, where there's some
>> process parsing a project with semantic awareness. Instead it just
>> launches guile (or some other repl) and parses the prompt string. As far
>> as I know it is really just sending text back and forth between a
>> scheme-mode buffer and a runing repl.
>
> Would this kind of tool be more useful than Geiser?  I find that
> auto-parsing of the project could really help refactoring stuff and jump
> to definition without having to evaluate every module.  The REPL can
> stay there for on the fly modification of the program of course, but
> perhaps a communication would be necessary between the auto-parser and
> the REPL.  What do you think?

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[Olivier Dion via]

On Fri, 11 Nov 2022, Jake Shilling <shilling.jake@gmail.com> wrote:
> Personally, I only use scheme for my guix configuration and I dont't
> think Geiser is missing anything for that perpose. After all, I want my
> dotfiles to always be evaluated within the global guile environment for
> my user.
>
> At the same time, I think that having tooling issolate some files from
> the global environment is important for any code base that is going to
> be distributed to other users. (e.g. I want SLIME/Cider to only think
> about modules that are available within the declared dependencies of a
> particular project). Of course, containerize a particular project fairly
> effectively with direnv or dir-locals.el.
>
> If I were using scheme for anything more serious, I would probably want
> something more like SLIME/Cider, but for my use case there's nothing
> missing.

I see.  Thanks for you input!

-- 
Olivier Dion
oldiob.dev

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 09:31:40 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> my configuration files, I have a toplevel script which updates the
> %load-path:
> 
> ```
> (when (current-filename)
>   (add-to-load-path
>    (dirname (current-filename))))
> ```
> 
> So when I load that file into the repl with C-c C-l all the subsequent
> use-modules work.

Hi Jake, thanks for the reply,

You have to do all that before geiser will pick up the source files in my guix checkout?

Just doing the following as recommended in the guix manual is not enough?

> (with-eval-after-load 'geiser-guile
>   (add-to-list 'geiser-guile-load-path "~/guix"))

My source checkout of guix is in `~/guix`.

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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

On 2022-11-11 12:40, jgart@dismail.de wrote:

> On Fri, 11 Nov 2022 09:31:40 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
>> my configuration files, I have a toplevel script which updates the
>> %load-path:
>> 
>> ```
>> (when (current-filename)
>>   (add-to-load-path
>>    (dirname (current-filename))))
>> ```
>> 
>> So when I load that file into the repl with C-c C-l all the subsequent
>> use-modules work.
>
> You have to do all that before geiser will pick up the source files in
> my guix checkout?

You would only need to do that for a script that is not included in
either your `GUILE_LOAD_PATH` environment variable or in
'geiser-guile-load-path. The directories set up in either of those
places will be used to initialize %load-path when the guile repl starts.

To give you a sense of where I'm using this: I have a repository [1]
cloned to ~/dotfiles, which contains a script that generates a
configuration for guix home. I want that script to know about other
modules I make in the same directory, but I don't what scheme programs I
work on in other places to be aware of my dotfiles helpers. Putting that
block at the top of the file is what makes that work (i.e. ~/dotfiles is
only in my %load-path after I evaluate ~/dotfiles/config.scm).

This same dotfiles repository also makes use of modules that come from
different channels (mostly the default guix channel and RDE [2]). I do
want these modules to be visible in ever guile repl though no matter
what script I'm working on, so I handle that by setting my
GUILE_LOAD_PATH:

```
GUILE_LOAD_PATH="/run/current-system/profile/share/guile/site/3.0:${HOME}/.config/guix/current/share/guile/site/3.0"
```

Any time I add a new channel and run `guix pull`, that channel is going
to be checked out to ${HOME}/.config/guix/current/share/guile/site/3.0
and be picked up by default. This works for me because I'm not actively
working on the guix source code, so I don't want to manage that as a
project cloned down manually. For me, guix is just a collection of
modules to use in my other scripts.

All that is to say, you only need to do something like the block above
if you have a directory that should only be visible to certain
projects/script files. If you add any directory to the
geiser-guile-load-path then it is going to be picked up anyway and you
don't need to do anything special.

[1] https://gitlab.com/shilling.jake/dotfiles/-/blob/master/config.scm#L5
[2] https://sr.ht/~abcdw/rde/

>
> Just doing the following as recommended in the guix manual is not enough?
>
>> (with-eval-after-load 'geiser-guile
>>   (add-to-list 'geiser-guile-load-path "~/guix"))
>
> My source checkout of guix is in `~/guix`.
>

That is definitly enouhg to make sure ~/guix is processed by guile and
then Gieser. The only caveat is that if you forget to update the
repository there, or forget to guix pull, then you could end up with
Geiser looking at a different version of the guix modules than what is
actually installed in your profile.

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 15:43:26 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> On 2022-11-11 12:40, jgart@dismail.de wrote:
> 
> > On Fri, 11 Nov 2022 09:31:40 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:

> That is definitly enouhg to make sure ~/guix is processed by guile and
> then Gieser. 

Hi Jake, I'll get back to your points above but I wanted to clarify that
it is not enough to just set the src repo checkout for Guix on a foreign
distro. Atleast, not on void linux.

I'm not able to geiser-edit-symbol-at-point at all successfully after setting
the basics as described in the Guix manual and as I described prior.

Maybe it only works out of the box as described in the manual if you
happen to be on Guix System but not on Void Linux?

Does Geiser work fine after being configured as described in
the guix manual on Ubuntu or Debian?

What can I do to debug what the issue is on my system (void linux)
with geiser?

I should check to see if some guix specific environment variables are
missing or improperly set in my bashrc or bash_profile?

I'm using bash on void linux.

all best,

jgart

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 15:42:13 -0600 jgart <jgart@dismail.de> wrote:
> On Fri, 11 Nov 2022 15:43:26 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> > On 2022-11-11 12:40, jgart@dismail.de wrote:

If I could just get geiser-edit-symbol-at-point to work I'll be the
happiest Guixer in the world. I could care less about the rest of Geiser
right now.

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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


>
> Maybe it only works out of the box as described in the manual if you
> happen to be on Guix System but not on Void Linux?

I haven't spent a lot of time with Guix on a foreign distro, but whenver
I have tried it there's been lots of weird problems that I didn't
understand. 

>
> What can I do to debug what the issue is on my system (void linux)
> with geiser?

I'm sure someone who actually knows what they're doing could help more
than me, but my thought would be to start by debugging guile outside of
Geiser. I would try to spin up a repl and see if I could import one of
the modules from ~/guix and check out what the %load-path ends up being.

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 17:06:07 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> I'm sure someone who actually knows what they're doing could help more
> than me, but my thought would be to start by debugging guile outside of
> Geiser. I would try to spin up a repl and see if I could import one of
> the modules from ~/guix and check out what the %load-path ends up being.

I have no problem loading guile (guix installed) third party modules or
guix modules (via `guix repl`).

Doing anything in geiser seems to not work except for running `M-x geiser` to launch a repl.

I can call geiser-edit-symbol-at-point but it doesn't do anything and
the *Messages* buffer doesn't say anything helpful...

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 16:15:18 -0600 jgart <jgart@dismail.de> wrote:
> On Fri, 11 Nov 2022 17:06:07 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> I can call geiser-edit-symbol-at-point but it doesn't do anything and
> the *Messages* buffer doesn't say anything helpful...

I was able to geiser-edit-symbol-at-point on a lambda* like the following

(lambda* (#:key inputs outputs #:allow-other-keys)
 ^^^^^

It opened the elf binary for it in emacs and I was able to pop-tag-mark back to where I was!

I feel like I've made some progress...

Re: geiser-edit-symbol-at-point

[jgart]

On Fri, 11 Nov 2022 18:07:49 -0600 jgart <jgart@dismail.de> wrote:
> I feel like I've made some progress...

I can also geiser-edit-symbol-at-point the following snippet

(format #t
^^^^^^^

It jumps me to the source location here:

/gnu/store/qlmpcy5zi84m6dikq3fnx5dz38qpczlc-guile-3.0.8/share/guile/3.0/ice-9/format.scm

But this doesn't work for geiser-edit-symbol-at-point because it is guix API code:

(add-after 'build 'install-xsession
^^^^^^^^^

It asks me to visit a tags table which is probably not what I want.

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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

On 2022-11-11 18:12, jgart wrote:

> But this doesn't work for geiser-edit-symbol-at-point because it is guix API code:
>
> (add-after 'build 'install-xsession
> ^^^^^^^^^

`add-after` might not be the best symbol to test on, because (with my
limited understanding of scheme) is not defined to be anything--it's
just used in the pattern matching for the `%modify-phases` macro:

```
(define-syntax %modify-phases
  (syntax-rules (delete replace add-before add-after)
    ((_ phases (delete old-phase-name))
     (alist-delete old-phase-name phases))
    ((_ phases (replace old-phase-name new-phase))
     (alist-replace old-phase-name new-phase phases))
    ((_ phases (add-before old-phase-name new-phase-name new-phase))
     (alist-cons-before old-phase-name new-phase-name new-phase phases))
    ((_ phases (add-after old-phase-name new-phase-name new-phase))
     (alist-cons-after old-phase-name new-phase-name new-phase phases))))
```

If I'm reading this right, I belive that this macro is looking for the
'add-after symbol--as a symbol--and not looking for any value referenced
by it.

I am able to run `geiser-edit-symbol-at-point` on `modify-phases`, but
not `add-after` (or related). I should also point out that Geiser only
recognizes `modify-phases` after I've already evaluated the evaluated
the form that imports the (gnu build utils) module. If I simply open the
file, start guile, and try to edit `modify-phases` nothing
happens. Geiser needs me to evaluate the (use-module (gnu build utils))
bit first.

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[jgart]

On Sat, 12 Nov 2022 10:48:54 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> 
> If I'm reading this right, I belive that this macro is looking for the
> 'add-after symbol--as a symbol--and not looking for any value referenced
> by it.

Does geiser work on the macroexpanded forms in %modify-phases that are
not macros?

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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

On 2022-11-14 09:01, jgart@dismail.de wrote:

> On Sat, 12 Nov 2022 10:48:54 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
>> 
>> If I'm reading this right, I belive that this macro is looking for the
>> 'add-after symbol--as a symbol--and not looking for any value referenced
>> by it.
>
> Does geiser work on the macroexpanded forms in %modify-phases that are
> not macros?

It does for me. Here's a snippet from the file I tested on:

```
(arguments
     `(#:bootstrap-scripts (list "autogen")
       #:make-flags (list "-C" "utils")
       #:configure-flags (list "--enable-start-stop-daemon"
                               "--disable-update-alternatives")
       #:phases
       (modify-phases %standard-phases
         (add-before 'bootstrap 'patch-autogen-shebang
           (lambda* (#:key bootstrap-scripts #:allow-other-keys)
             (for-each patch-shebang (append bootstrap-scripts))
             (let ((get-version "printf \"%s\" \"1.20.12\"")
                   (port (open-file "get-version" "w")))
               (format port get-version)
               (close-port port))))
         (add-after 'configure 'build-lib
           (lambda* (#:rest _)
             (invoke "make" "-C" "lib"))))))
```

If I evaluate this file, then call `geiser-edit-symbol-at-point` on
`invoke` in the last line, I get taken to `guix/build/utils.scm` as
expected. None of the standard guile functions work for me though; if I
try to navigate to `close-port` or `for-each` nothing happens. I can run
C-c C-d C-d on any of those, however, and navigate from the
documentation to the manual.

I also want to clarify that this does work for me on the macro itself,
`modify-phases`, just not on the symbols used by the macro for pattern
matching (`add-before`, `add-after`, etc).

-- 
Best regards,
Jake Shilling

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

Re: geiser-edit-symbol-at-point

[jgart]

On Mon, 14 Nov 2022 10:16:33 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
> On 2022-11-14 09:01, jgart@dismail.de wrote:

> If I evaluate this file ...

Cool, what did you do to evaluate the file exactly? Where you on Guix System
when this worked for you?

Re: geiser-edit-symbol-at-point

[Jake Shilling]

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

On 2022-11-14 16:38, jgart@dismail.de wrote:

> On Mon, 14 Nov 2022 10:16:33 -0500 Jake Shilling <shilling.jake@gmail.com> wrote:
>> On 2022-11-14 09:01, jgart@dismail.de wrote:
>
>> If I evaluate this file ...
>
> Cool, what did you do to evaluate the file exactly?

I usually use `geiser-load-file` (C-c C-l), but for incremental changes
as I'm working on a single file, I'll run `geiser-eval-definition` after
I change some top level form.

> Where you on Guix System when this worked for you?

I was. I haven't experimented in any serious way with guix on a foreign
distro.


-- 
Best regards,
Jake Shilling

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