Re: Re Re: Why not include all ELPA packages in an Emacs release?

Re: Re Re: Why not include all ELPA packages in an Emacs release?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

Message-ID: <86r0dksk1x.fsf@gnu.org>

>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > If there are packages on ELPA which we consider to be a must for users
>> > (I don't think there are, but maybe I'm forgetting something), lets
>> > add them to core instead.
>>
>> If Emacs considers in-buffer completion an important feature, then I'd
>> say corfu and cape are must.  vertico and marginalia are also must in my
>> book since they offer a better experience with vertical minibuffer
>> completion.

> If people want them, and their developers agree, we can add them.

<irony>At this point, why not company, which BTW works nicely both on
windows and -nw Emacs?</irony>
<seriously>For every package you think of integrating, there will be a lot
of people how use a different package for the functionality, so this spells
exchanges without end here and a lot of users frustrated in the world
outside the list </seriously>

>> And while we're at it: There are sometimes requests for adding AUCTeX to
>> core.  Do you have an opinion about that?
>
>I don't mind.  But let's hear what others think.

Well, AUCTeX was so feature-bloated that made me start using vanilla Emacs
and writing the things I really needed myself. So grateful it existed,
because it made my elisp evolve :-)

Now seriously, One of the nicest things in Emacs is the package repo(s).
I have the Emacs I want because we have use-package (and that is not so
long ago)
to make our lives (relatively) easy. And I dread to think what would happen
WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap in
Linux,
etc.) if we start shipping everything in it.

My .2 cents
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2531 bytes --]

Re: Re Re: Why not include all ELPA packages in an Emacs release?

[Philip Kaludercic]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

> Message-ID: <86r0dksk1x.fsf@gnu.org>
>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>> > If there are packages on ELPA which we consider to be a must for users
>>> > (I don't think there are, but maybe I'm forgetting something), lets
>>> > add them to core instead.
>>>
>>> If Emacs considers in-buffer completion an important feature, then I'd
>>> say corfu and cape are must.  vertico and marginalia are also must in my
>>> book since they offer a better experience with vertical minibuffer
>>> completion.
>
>> If people want them, and their developers agree, we can add them.
>
> <irony>At this point, why not company, which BTW works nicely both on
> windows and -nw Emacs?</irony>

I unironically think that this might be a better choice.

> <seriously>For every package you think of integrating, there will be a lot
> of people how use a different package for the functionality, so this spells
> exchanges without end here and a lot of users frustrated in the world
> outside the list </seriously>

Bundling a package with Emacs is not the same as enabling it by default.
I guess the exception are major modes, where it makes sense to have
these added to auto-mode-alist, but otherwise something like Company
shouldn't be enabled by default.

>>> And while we're at it: There are sometimes requests for adding AUCTeX to
>>> core.  Do you have an opinion about that?
>>
>>I don't mind.  But let's hear what others think.
>
> Well, AUCTeX was so feature-bloated that made me start using vanilla Emacs
> and writing the things I really needed myself. So grateful it existed,
> because it made my elisp evolve :-)

This sounds like a LaTeX/AUCTeX-specific issue.  IIUC, you prefer the
built-in latex-mode that AUCTeX supersedes, right?  Or what do you mean
by bloated?

> Now seriously, One of the nicest things in Emacs is the package repo(s).
> I have the Emacs I want because we have use-package (and that is not so
> long ago)
> to make our lives (relatively) easy. And I dread to think what would happen
> WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap in
> Linux,
> etc.) if we start shipping everything in it.

There are still plenty of cases where people cannot just install
packages over the net and are stuck with whatever Emacs is bundled with.
ELPA remains useful to upgrade packages that don't depend on new core
features, but having "blessed" packages bundled without having to
explain to new-comers "well yes, Emacs can do that but you have to
install foo, bar and baaz first" (here "foo", "bar" and "baaz" are more
often than not some weird names that they cannot remember in the first
place) is helpful and underappreciated by many.

WRT the package size, I wouldn't worry that much.  Even a large package
like AUCTeX is just under 10MB in my /elpa/ directory.  The mean package
side on ELPA is about 100-150KB.  Packages like Debian that don't
bundled .el sources (instead just using .elc) by default might be even
better off.

> My .2 cents

-- 
	Philip Kaludercic on peregrine

Re: Re Re: Why not include all ELPA packages in an Emacs release?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]

Hi

On Wed, 29 May 2024 at 22:36, Philip Kaludercic <philipk@posteo.net> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > Message-ID: <86r0dksk1x.fsf@gnu.org>
> >
> >>> Eli Zaretskii <eliz@gnu.org> writes:
> >>>
> >>> > If there are packages on ELPA which we consider to be a must for
> users
> >>> > (I don't think there are, but maybe I'm forgetting something), lets
> >>> > add them to core instead.
> >>>
> >>> If Emacs considers in-buffer completion an important feature, then I'd
> >>> say corfu and cape are must.  vertico and marginalia are also must in
> my
> >>> book since they offer a better experience with vertical minibuffer
> >>> completion.
> >
> >> If people want them, and their developers agree, we can add them.
> >
> > <irony>At this point, why not company, which BTW works nicely both on
> > windows and -nw Emacs?</irony>
>
> I unironically think that this might be a better choice.
>

Hmm... nice to hear... thanks :-)

>  > <seriously>For every package you think of integrating, there will be a
> lot
> > of people how use a different package for the functionality, so this
> spells
> > exchanges without end here and a lot of users frustrated in the world
> > outside the list </seriously>
>
> Bundling a package with Emacs is not the same as enabling it by default.
>
+1

> I guess the exception are major modes, where it makes sense to have
> these added to auto-mode-alist, but otherwise something like Company
> shouldn't be enabled by default.
>
Couldn't agree more...

>
> >>> And while we're at it: There are sometimes requests for adding AUCTeX
> to
> >>> core.  Do you have an opinion about that?
> >>
> >>I don't mind.  But let's hear what others think.
> >
> > Well, AUCTeX was so feature-bloated that made me start using vanilla
> Emacs
> > and writing the things I really needed myself. So grateful it existed,
> > because it made my elisp evolve :-)
>
> This sounds like a LaTeX/AUCTeX-specific issue.  IIUC, you prefer the
> built-in latex-mode that AUCTeX supersedes, right?  Or what do you mean
> by bloated?
>

Jup, that was a purely LaTeX issue. And yes, I didn't have time to learn
all the specifics
of AUCTeX and did some customisation + yasnippets to get my phD thesis
written.
At that time, a switch from MSWord/OpenOffice to LaTeX was churning all my
free CPU cycles,
because I had work and real life in parallel.

> > Now seriously, One of the nicest things in Emacs is the package repo(s).
> > I have the Emacs I want because we have use-package (and that is not so
> > long ago)
> > to make our lives (relatively) easy. And I dread to think what would
> happen
> > WTR to size of the distributable object (.app in macos, .rpm/.deb/.snap
> in
> > Linux,
> > etc.) if we start shipping everything in it.
>
> There are still plenty of cases where people cannot just install
> packages over the net and are stuck with whatever Emacs is bundled with.
>

Good point...


> ELPA remains useful to upgrade packages that don't depend on new core
> features, but having "blessed" packages bundled without having to
> explain to new-comers "well yes, Emacs can do that but you have to
> install foo, bar and baaz first" (here "foo", "bar" and "baaz" are more
> often than not some weird names that they cannot remember in the first
> place) is helpful and underappreciated by many.
>

I get your point... and right, there are situations where you just can't
get the
packages from the Internet.

WRT the package size, I wouldn't worry that much.  Even a large package
> like AUCTeX is just under 10MB in my /elpa/ directory.  The mean package
> side on ELPA is about 100-150KB.  Packages like Debian that don't
> bundled .el sources (instead just using .elc) by default might be even
> better off.
>

But just keep in mind that there are situations, where the platform must
deploy
Emacs on, might not be as relaxed WRT disk space... And it's not about a
specific
package, it's about a trickle of packages becoming a flood...

> My .2 cents
>
> --
>         Philip Kaludercic on peregrine
>

Best, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 6745 bytes --]

Re: Re Re: Why not include all ELPA packages in an Emacs release?

[Philip Kaludercic]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

>> >>> And while we're at it: There are sometimes requests for adding AUCTeX
>> to
>> >>> core.  Do you have an opinion about that?
>> >>
>> >>I don't mind.  But let's hear what others think.
>> >
>> > Well, AUCTeX was so feature-bloated that made me start using vanilla
>> Emacs
>> > and writing the things I really needed myself. So grateful it existed,
>> > because it made my elisp evolve :-)
>>
>> This sounds like a LaTeX/AUCTeX-specific issue.  IIUC, you prefer the
>> built-in latex-mode that AUCTeX supersedes, right?  Or what do you mean
>> by bloated?
>>
>
> Jup, that was a purely LaTeX issue. And yes, I didn't have time to learn
> all the specifics
> of AUCTeX and did some customisation + yasnippets to get my phD thesis
> written.
> At that time, a switch from MSWord/OpenOffice to LaTeX was churning all my
> free CPU cycles,
> because I had work and real life in parallel.

[...]

> WRT the package size, I wouldn't worry that much.  Even a large package
>> like AUCTeX is just under 10MB in my /elpa/ directory.  The mean package
>> side on ELPA is about 100-150KB.  Packages like Debian that don't
>> bundled .el sources (instead just using .elc) by default might be even
>> better off.
>>
>
> But just keep in mind that there are situations, where the platform must
> deploy
> Emacs on, might not be as relaxed WRT disk space... And it's not about a
> specific
> package, it's about a trickle of packages becoming a flood...

I can imagine that a distribution like Debian can choose to distribute
two package.  The regular Emacs, that would bundle the selected ELPA
packages and "emacs-minimal" that wouldn't (and perhaps even remove some
more, like games or some stuff like that).

>> My .2 cents
>>
>> --
>>         Philip Kaludercic on peregrine
>>
>
> Best, /PA

-- 
	Philip Kaludercic on peregrine

Re: Re Re: Why not include all ELPA packages in an Emacs release?

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

Hi Philip,

On Thu, 30 May 2024 at 08:31, Philip Kaludercic <philipk@posteo.net> wrote:

> Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:
>
> > But just keep in mind that there are situations, where the platform must
> > deploy
> > Emacs on, might not be as relaxed WRT disk space... And it's not about a
> > specific
> > package, it's about a trickle of packages becoming a flood...
>
> I can imagine that a distribution like Debian can choose to distribute
> two package.  The regular Emacs, that would bundle the selected ELPA
> packages and "emacs-minimal" that wouldn't (and perhaps even remove some
> more, like games or some stuff like that).
> ...
> --
>         Philip Kaludercic on peregrine
>
And maybe, one should start thinking into including this option in the
emacs Makefile. Something
like a

make install-mininal

For those who self-compile ;-)

Best, /PA

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 1902 bytes --]

A small(er) Emacs (was: Why not include all ELPA packages in an Emacs release?)

[Stefan Monnier]

> But just keep in mind that there are situations, where the platform
> must deploy Emacs on, might not be as relaxed WRT disk space... And
> it's not about a specific package, it's about a trickle of packages
> becoming a flood...

Emacs tarballs have grown over the years, some versions growing
very significantly.  Is it a concern?  Yes, to some extent.
Is it worth the effort of making a "slim Emacs" option?  Apparently not
because I don't know of anyone who has gone through the effort of
actually making it a reality.

IME if your target has enough disk constraints that installing the
full Emacs is a concern, you're probably better served by one of:
- Another editor (e.g. Zile).
- Tramp.
- just installing the full Emacs anyway.

If you think you have a good use case where a "slim Emacs" is better
than the above options, then by all means, get working on a patch.
If it's simple&clean enough we may even accept it.
I'm not holding my breath.


        Stefan