Making seq.el an Elpa core package?

Making seq.el an Elpa core package?

[Nicolas Petton]

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

Hi,

I'm thinking about removing seq.el from GNU Elpa and make it a core
package instead.  The package is currently maintained both in Emacs and
Elpa, removing the duplication would be good.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Making seq.el an Elpa core package?

[Juri Linkov]

> I'm thinking about removing seq.el from GNU Elpa and make it a core
> package instead.  The package is currently maintained both in Emacs and
> Elpa, removing the duplication would be good.

This package is so useful that it should be preloaded in loadup.el.

It introduces to Elisp programming many necessary idioms that are
expected from any modern programming language to help writing more
clear and readable code.

Recently I implemented a new feature for isearch using seq.el.
The resulting code is much shorter with seq than it would be
when using ugly old style like `(delq nil (mapcar ...))'.

But I can't submit a patch for isearch.el because currently
seq.el is not loaded by default.

Re: Making seq.el an Elpa core package?

[Nicolas Petton]

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

Juri Linkov <juri@linkov.net> writes:

> This package is so useful that it should be preloaded in loadup.el.

As of today seq.el requires cl-lib, but I think I could easily get rid
of the dependency.  Anyway IIRC this was discussed some years ago when I
started working on seq.el, and at the time I also thought such a library
should come preloaded, but the opinion on this list was quite divided.

> It introduces to Elisp programming many necessary idioms that are
> expected from any modern programming language to help writing more
> clear and readable code.

Thanks, I'm glad you like it :-)

> Recently I implemented a new feature for isearch using seq.el.
> The resulting code is much shorter with seq than it would be
> when using ugly old style like `(delq nil (mapcar ...))'.
>
> But I can't submit a patch for isearch.el because currently
> seq.el is not loaded by default.

Oh right, because isearch.el is itself preloaded.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Making seq.el an Elpa core package?

[Phillip Lord]

Nicolas Petton <nicolas@petton.fr> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> This package is so useful that it should be preloaded in loadup.el.
>
> As of today seq.el requires cl-lib, but I think I could easily get rid
> of the dependency.  Anyway IIRC this was discussed some years ago when I
> started working on seq.el, and at the time I also thought such a library
> should come preloaded, but the opinion on this list was quite divided.

I think that there is a lot to be said for explicit dependencies between
packages and minimizing the number of things that are pre-loaded. Most
packages load so quickly these days that the user rarely notices; or
wouldn't if we removed the "loading" messages.


>> It introduces to Elisp programming many necessary idioms that are
>> expected from any modern programming language to help writing more
>> clear and readable code.
>
> Thanks, I'm glad you like it :-)
>
>> Recently I implemented a new feature for isearch using seq.el.
>> The resulting code is much shorter with seq than it would be
>> when using ugly old style like `(delq nil (mapcar ...))'.
>>
>> But I can't submit a patch for isearch.el because currently
>> seq.el is not loaded by default.
>
> Oh right, because isearch.el is itself preloaded.


What would happen is isearch.el were not pre-loaded?

Phil

Re: Making seq.el an Elpa core package?

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Date: Sun, 10 Mar 2019 11:48:50 +0000
> Cc: Emacs Devel <emacs-devel@gnu.org>, Juri Linkov <juri@linkov.net>
> 
> I think that there is a lot to be said for explicit dependencies between
> packages and minimizing the number of things that are pre-loaded. Most
> packages load so quickly these days that the user rarely notices; or
> wouldn't if we removed the "loading" messages.

The principle always was that we preload packages which will be loaded
by any session at startup or very soon afterwards anyway.  I don't
think it matters how long do they load, because loading just once will
always be faster.

Re: Making seq.el an Elpa core package?

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Date: Sun, 10 Mar 2019 11:48:50 +0000
>> Cc: Emacs Devel <emacs-devel@gnu.org>, Juri Linkov <juri@linkov.net>
>> 
>> I think that there is a lot to be said for explicit dependencies between
>> packages and minimizing the number of things that are pre-loaded. Most
>> packages load so quickly these days that the user rarely notices; or
>> wouldn't if we removed the "loading" messages.
>
> The principle always was that we preload packages which will be loaded
> by any session at startup or very soon afterwards anyway.  I don't
> think it matters how long do they load, because loading just once will
> always be faster.


Okay. I can see this for packages like "simple", perhaps "nadvice". I
struggle a bit with "language/sinhala", "uniquify" or even "isearch".

Phil

Re: Making seq.el an Elpa core package?

[Stefan Monnier]

> Okay. I can see this for packages like "simple", perhaps "nadvice". I
> struggle a bit with "language/sinhala", "uniquify" or even "isearch".

For uniquify, it's simply because this feature is enabled by default ;-)
For Isearch, it's because we expect that the vast majority of Emacs
sessions will make use of it.

For language/* IIRC the issue is that we don't have any autoload
mechanism for those things.


        Stefan

Re: Making seq.el an Elpa core package?

[Stefan Monnier]

> I'm thinking about removing seq.el from GNU Elpa and make it a core
> package instead.  The package is currently maintained both in Emacs and
> Elpa, removing the duplication would be good.

IIUC you mean to remove it from elpa.git but keep it in GNU ELPA by
publishing the seq.el that's in emacs.git as a :core package.

LGTM,


        Stefan

Re: Making seq.el an Elpa core package?

[Nicolas Petton]

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

> IIUC you mean to remove it from elpa.git but keep it in GNU ELPA by
> publishing the seq.el that's in emacs.git as a :core package.

Yes, that's exactly what I mean.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]