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

Previous Next

Full log

Message #38 received at 48237 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Arun Isaac <arunisaac <at> systemreboot.net>, 48237 <at> debbugs.gnu.org,
 Xinglu Chen <public <at> yoctocell.xyz>
Subject: Re: [bug#48237] [PATCH] gnu: emacs-consult: Add
 ‘emacs-ve
Date: Tue, 07 Sep 2021 09:05:09 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.