[bug#33598] Optimizations for emacs-clang-format and emacs-clang-rename

["Ludovic Courtès" <ludo@gnu.org>]

Pierre Neidhardt <mail@ambrevar.xyz> skribis:

> The benefit of separate Emacs packages is if the Emacs library can be used
> without installing the parent package to the user profile.
>
> For instance, emacs-clang-rename can be installed and it will work while the
> user does not have to install clang.  (Clang remains an input, obviously.)
>
> For this reason, "package-elisp-from-package" gives maximal flexibility in my
> opinion.

Yes, I agree that it makes a lot of sense for ‘emacs-clang-rename’ for
instance.  I’m just unsure whether the approach generalize to other
packages.

> Currently, there are a few more packages.  We can look up "emacs-build-system"
> outside emacs.scm to find them (e.g. agda2).
>
> Off the top of my head, there is also asymptote.

I’m not convinced sure ‘emacs-agda2-mode’ and ‘asymptote’ need to be
changed; it doesn’t look like a clear win, dunno.

For example, ‘package-elisp-from-package’ preserves the name, synopsis,
and description, so you end up having to do:

  (define foo
    (package
      (inherit (package-elisp-from-package x))
      (name "emacs-foo")
      (license …)
      (synopsis …)
      (description …)))

… which I think it a marginal improvement compared to
‘emacs-agda2-mode’.  Also, the “find *.el” approach may not work out of
the box for all cases, so the procedure may need to be tweaked further,
etc.

> Now to the ideal place for package-elisp-from-package: it seems that no existing
> file would be a fit.  So what about guix/utils/emacs.scm?  Having a separate
> file would make sure we run into other meta-circular dependency issues.

Circular, not meta-circular.  ;-)

So yeah, (guix utils emacs) is one option; another one would be to trim
the list of modules emacs.scm depends on, such that we don’t have this
issue in the first place (that requires care, though.)

However, my suggestion would be to use ‘package-elisp-from-package’ as
Tim intended in the original patch, keeping the procedure private to
llvm.scm, and generalize if and when we see other use cases.

How does that sound?

Ludo’.