Op 22-11-2023 om 21:53 schreef Simon Tournier:
Toggle quote (6 lines)
> On mar., 21 nov. 2023 at 19:01, Maxime Devos <maximedevos@telenet.be> wrote:
>
>> Yes, it is official, but the question was how the bundling is not a bug (and
>> implicitly, whether it is bundling), not whether the bundling is official.
>
> The bundling is not a bug because it is how Emacs is developed.
That's what they all say. What's do different about Emacs that we
should accept this from Emacs and not from other bundlers? Like, sure,
there are some differences in how Emacs bundles things compared to
others, but how do these differences matter?
Toggle quote (3 lines)
> The
> term “bundle“ – which would potentially imply being unbundled by Guix
> packagers – is misleading.
What is misleading about the "term" bundle / misleading about
potentially being unbundled by Guix packagers?
Toggle quote (13 lines)
> Emacs maintainers grant some packages and make them part of Emacs as
> builtin package; whatever where these packages are developed or if these
> packages follow another release schedule than the Emacs release
> schedule. The section “New Modes and Packages in Emacs X.Y” of the NEWS
> file for each release (NEWS.28, NEWS,27, etc.) lists such promoted
> packages. Please note that Emacs 29 introduces a “New user option
> 'package-install-upgrade-built-in'”, as mentioned in NEWS.
>
> For instance, the packages widget.el or woman.el or many others were
> initially developed outside the Savannah Emacs tree, then integrated
> (being promoted builtin), and now the original development location is
> gone – which means all the maintenance burden for these builtin packages
> is now done by Emacs maintainers.
Yes, Emacs integrates outside things, I've heard it already ...
If we're talking about misleading statements ...
For widget and woman, sure, I'll take your word for it is fully merged
in Emacs (both the literal code & development (& maintenance)). But I'm
talking about emacs-transient (not widget or woman), and note, as I
pointed out previously, emacs-transient development location appears to
Tree) -- there's even a new commit 8 hours ago, and it doesn't seem to
be disappearing anytime soon.
If you have examples, please only use non-misleading examples ...
Toggle quote (2 lines)
> Once builtin, the code of a package distributed with GNU Emacs is
> maintained by Emacs maintainers and fully part of GNU Emacs.
Yes, and? How does being fully part of GNU Emacs and being maintained
by Emacs maintainers make it any less bundling? There is more to
development than maintenance.
Even if we were to exclude situations like this from a definition of
‘bundling’, that just changes the name of the thing, there still remain
some benefits to what you aren't calling unbundling / downsides to what
you aren't calling bundling.
Toggle quote (15 lines)
> As explicitly commented in the header of transient.el that comes with
> Emacs:
>
> --8<---------------cut here---------------start------------->8---
> ;;; transient.el --- Transient commands -*- lexical-binding:t -*-
>
> ;; Copyright (C) 2018-2023 Free Software Foundation, Inc.
>
> ;; Author: Jonas Bernoulli <jonas@bernoul.li>
> ;; URL: https://github.com/magit/transient
>
> [...]
>
> ;; This file is part of GNU Emacs.
> --8<---------------cut here---------------end--------------->8---
Indeed, bundled dependencies are part of what it is bundled inside.
And? How does this extra comment matter w.r.t. whether it is bundling
and whether the bundling is to be tolerated?
Toggle quote (1 lines)
> The collision is a bug. The report of bundled is not a bug.
If that's your opinion, please give you argument on how the bundling of
emacs-transient, or whatever you want to call it instead of ‘bundling’,
is not a bug.
--- (From: Mekeor Milere)
Toggle quote (1 lines)
> It might be possible to cut out some parts of Emacs so that emacs-minimal is more minimal. But I think this could become quite complicated because we don't know exactly which parts of Emacs are needed to build Emacs-related packages since they might rely on any Elisp code during compile-time. Also, more generally, it'd be hard to decide which parts are not needed, i.e. where to draw the line etc. All in all, I don't think that it's worth the effort and maintenance.
If making emacs-mnimal more minimal is too complicated, don't do it
then, just replace the bundled copy with an up-to-date (source) version,
as I proposed previously.
Also, I don't think I proposed minimalising Emacs to only what's needed
to build Emacs-related packages (though I could easily be
misremembering) -- IIRC, I only proposed minimalising it to the extent
of excluding the bundled Emacs packages.
Toggle quote (1 lines)
> TANGENTIALLY: I'd like to mention that this topic becomes sort of a problem when (1) you have installed Emacs with "guix install emacs-next --with-branch=emacs-next=master" or similar; and (2) you installed some Emacs-related package via Guix, which propagates another Emacs-related package that is also built into Emacs. This would cause a downgrade of that propagated, built-in, Emacs-related package. E.g. this happens with emacs-consult-eglot which propagates emacs-eglot which is also built into Emacs itself. A work-around is to overwrite the input like this: "guix install emacs-next emacs-consult-eglot --with-input=emacs-eglot=emacs-next --with-branch=emacs-next=master".
No? Unless you do "--with-branch=emacs-next=something-old" or the like,
you will never get a downgrade -- you will not get an automatic upgrade
to what's bundled in Emacs-next, but:
(a) you won't get anything older than what is currently packaged in
Guix. (Hence, not a downgrade.)
(b) and you asked for a latest emacs, not a latest emacs-eglot.
You might even get something newer than in the master branch of Emacs,
if the Emacs maintainers haven't merged in the latest version yet.
Also, I don't get what "--with-input=emacs-eglot=emacs-next" is supposed
to do. Like, good for AOT, but this is not a bug report about AOT and
AFAIK Emacs has automatic recompilation.
Toggle quote (3 lines)
> If you want to know which built-in packages are distributed separately via GNU Elpa, search the following file for ":core". Note that only a subset of those might be packaged separately in Guix.
>
> https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages
I don't want to know. I use Guix as package manager, not Emacs -- I
don't really care whether a hypothetical package is distributed via Elpa.
Best regards,
Maxime Devos.
