[bug#72994] manifest.scm and emacs-specific things

["Danny Milosavljevic" <dannym@scratchpost.org>]

Hi!

> > On Mon, 16 Sep 2024 20:01 +0200 
> > dannym@friendly-machines.com wrote:
> >> The idea of this patch is that emacs will automatically set up
> >> whatever it needs to in order to make the REPL work (including the
> >> finding of the boundaries of the current expression that the emacs
> >> package needs for "send expression at point to REPL") without weird
> >> dependencies bleeding explicitly into the user profile or into the
> >> local directory's manifest.
> 
> Thanks for explaining!
> 
> > You could write a meta package à la "julia stuff for emacs-julia-snail"
> > and mention that in the description, no?
> 
> Yes, sounds like a good idea to me. WDYT, Danny?

I'm not yet sure.

I can of course add a "julia-toolchain" or something but it's really NOT
a julia toolchain thing. It's a local emacs-julia-snail thing that emacs
punted to some other language (as emacs is wont to do--delegate
things to other processes/languages/...).

A lot of dynamic languages do something like this in emacs and will
run into similar problems. Whatever the official way to do, we should
decide what to do and document it.

(I do think it's a good design to ask the actual Julia REPL about things
instead of reimplementing a Julia parser in elisp. That way it stays
current with reality)

The propagated inputs I would have added is so it WOULD conflict and
fail if you tried to add another Julia parser library (fail guix shell
on purpose!).

That's because, like most dynamic languages, you really can't load
two different modules that are named the same into the same
runtime without doing unholy things first. Otherwise, it would just
not do anything and use the existing one--which is probably not
what you wanted.

For the odd case when you are hacking on cstparser itself, you can
always not use the REPL and not use buffer-env. As you saw before,
julia-cstparser and julia-tokenize are currently NOT optional in
emacs anyway--the REPL won't start without--and with a totally
inscrutable error message that tries to make it julia's fault (it isn't).

So what I'm envisioning is documenting emacs-buffer-env like that:

(define-public emacs-buffer-env
  (package
    ...
    (description "In emacs, emacs-buffer-env can pick up manifest.scm from a
project directory automatically.

The contents of manifest.scm should be as follows:
(specifications->manifest (list

...
@item for Julia, it is recommended to add "julia-emacs-toolchain"
...
))
")))
Or something?

Because the following would leak emacs implementation details (arguably in a lot of cases!):

    (description "In emacs, emacs-buffer-env can pick up manifest.scm from a
project directory automatically.

The contents of manifest.scm should be as follows:
(specifications->manifest (list

@item for C and C++, it is recommended to add "gcc-toolchain" "binutils" "ccls" "bear"
@item for Python, it is recommended to add "python" "python-debugpy" "python-lsp-server"
@item for LaTeX, it is recommended to add "texlive-minted" "texlive-latex-bin" "dvisvgm"
@item for Prolog, it is recommended to add "swi-prolog" "emacs-ediprolog"
@item for Julia, it is recommended to add "julia" "julia-cstparser" "julia-tokenize"
@item for Vala, it is recommended to add "vala" "gcc-toolchain" "binutils" "vala-language-server" "gobject-introspection" "pkg-config"
        "meson" "ninja"
        ;; Note: That's the wrong glib
        "glib"
        ;; Note: That's the wrong gtk+
        "gtk+"
@item for Go, it is recommended to add "go"
@item for Rust, it is recommended to add "rust" "rust:cargo" "gcc-toolchain"
@item for R, it is recommended to add "r"
@item for Rust, it is recommendeed to add "ruby"
@item for Haskell, it is recommended to add "ghc" "gcc-toolchain"
@item for Java, it is recommended to add "openjdk" "openjdk:jdk"
@item for Zig, it is recommended to add "zig" "zig-zls"
@item for Perl, it is recommended to add "perl"
@item for SBCL, it is recommended to add "sbcl"
@item for Node, it is recommended to add "node"
@item for FPC, it is recommended to add "fpc"
@item for Ocaml, it is recommended to add "ocaml"
@item for Racket, it is recommended to add "racket"
@item for Chicken, it is recommended to add "chicken"
@item for D, it is recommended to add "dub" "ldc" "gcc-toolchain"
@item for Nim, it is recommended to add "nim"

))
")))

Adding julia-cstparser julia-tokenize inside julia-toolchain would be weird, no?

Also, for example for Python, worse, there's a python LSP server emacs thing, OR
there's a non-LSP emacs thing that asks the Python REPL directly  (!). I actually
prefer the latter because C-M-x works in emacs Python then (but C-M-x doesn't
work with python-debugpy and python-lsp-server in emacs--at least not for me).

I think making a public package "julia-emacs-toolchain" would be less weird.

(define-public julia-emacs-toolchain
  (package
    ...
    (propagated-inputs (list julia julia-cstparser julia-tokenize))))

Like that?

Which variant exactly do we want? Do we want end users to create
"manifest.scm"s like that, i.e. should those "xxx-emacs-toolchain"
package names be part of a Guix stable interface ?

emacs-julia-snail would not propagate julia-emacs-toolchain
then? Or would it?

(Personally, I think in an ideal world, *emacs* would run in its own
guix profile and when you do M-x list-packages in emacs and install
a package it would just install it into its emacs profile using
"guix package"[1]. Somehow, the emacs environment so configured
should not bleed into processes started by the user inside emacs.
But that's a long way off maybe and not sure whether it would be
a good idea.
In any case it should be *almost* independent of this here)