[bug#48237] [PATCH] gnu: emacs-consult: Add ‘emacs-ve

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Montag, den 06.09.2021, 19:17 -0400 schrieb Maxim Cournoyer:
> [...]
> 
> Thanks for explaining.  It makes sense, although there would probably
> be exceptions.  I'm thinking for example about emacs-elpy, for which
> not propagating optional dependencies would render the package nearly
> useless out of the box.
True, that's why those have to be evaluated on a case-by-case basis. 
FWIW, I do think that not propagating auto-completion frameworks by
more or less unrelated packages is a good rule of thumb, however.

> > For example, an Emacs package might require emacs-dash to function
> > at all and might install some autocompletion stuff with emacs-
> > autocomplete or emacs-company (perhaps even both).  emacs-dash
> > absolutely must be propagated, but unless you're already using
> > autocomplete or company and thus have them in your manifest, you
> > probably don't want them to be installed by emacs-foo.  Does this
> > make sense?
> 
> From a purity sense, yes, but propagating autocomplete or company
> wouldn't cause any problems in practice, no?
Packages installed by Guix do contribute to startup times (guix-emacs
autoloads etc.) and if you don't care about a given feature you might
also want to update one package separately from the others (because the
spacebar heater got deactivated), which would lead to a conflict of
propagated inputs.  I'm not sure how well the latter would work in
practice, but it's a thing to think about especially with libraries
that would otherwise propagate nothing.

> As another possible option to explore to avoid propagation could be
> to develop a runpath equivalent for the Emacs compiled format
> (.elc).  More work, but more definitive!
I think the bigger problem in Emacs is the lacking module system.  Even
if you have runpaths, you're still polluting the same global namespace.

Thanks