unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Autloading seq.el functions
@ 2019-10-23 16:00 Stefan Monnier
  2019-10-23 18:05 ` Eli Zaretskii
  2019-10-24 11:43 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 7+ messages in thread
From: Stefan Monnier @ 2019-10-23 16:00 UTC (permalink / raw)
  To: emacs-devel

I see we have currently 2 functions autoloaded from seq.el:
seq-find and seq-position.

While I can live with it, I find it unsatisfactory: these seem
completely arbitrary since they're not in any obvious sense more "entry
points" than other functions in that library.

Maybe there are good reasons why these two specifically need to be
autoloaded while it's not nearly as important for the others, but if so
I'd like to have some comment explaining it, otherwise it's odd to see
some package use `seq-*` functions without requiring `seq` while most
others have to require `seq`.


        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-23 16:00 Autloading seq.el functions Stefan Monnier
@ 2019-10-23 18:05 ` Eli Zaretskii
  2019-10-24 11:43 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2019-10-23 18:05 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 23 Oct 2019 12:00:58 -0400
> 
> I see we have currently 2 functions autoloaded from seq.el:
> seq-find and seq-position.
> 
> While I can live with it, I find it unsatisfactory: these seem
> completely arbitrary since they're not in any obvious sense more "entry
> points" than other functions in that library.

AFAIR, they are autoloaded because some preloaded code can need them
in some situations.

> Maybe there are good reasons why these two specifically need to be
> autoloaded while it's not nearly as important for the others, but if so
> I'd like to have some comment explaining it, otherwise it's odd to see
> some package use `seq-*` functions without requiring `seq` while most
> others have to require `seq`.

Sure, comments that explain the reasons are welcome.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-23 16:00 Autloading seq.el functions Stefan Monnier
  2019-10-23 18:05 ` Eli Zaretskii
@ 2019-10-24 11:43 ` Lars Ingebrigtsen
  2019-10-26 22:17   ` Juri Linkov
  1 sibling, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-24 11:43 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

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

> I see we have currently 2 functions autoloaded from seq.el:
> seq-find and seq-position.
>
> While I can live with it, I find it unsatisfactory: these seem
> completely arbitrary since they're not in any obvious sense more "entry
> points" than other functions in that library.

Eli suggested this methodology as a way to use seq.el in pre-dumped
files without pre-dumping seq.el in Emacs (and as a way to determine
whether seq.el is really needed).  I suspect that we'll end up (after a
year or two) having all the functions in seq.el ;;;###autoloaded.

> Maybe there are good reasons why these two specifically need to be
> autoloaded while it's not nearly as important for the others, but if so
> I'd like to have some comment explaining it, otherwise it's odd to see
> some package use `seq-*` functions without requiring `seq` while most
> others have to require `seq`.

That's really an intermediary artefact while this is being worked out --
I suspect that in Emacs 29 no packages will have to require seq. 

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-24 11:43 ` Lars Ingebrigtsen
@ 2019-10-26 22:17   ` Juri Linkov
  2019-10-27  4:49     ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Juri Linkov @ 2019-10-26 22:17 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Monnier, emacs-devel

>> I see we have currently 2 functions autoloaded from seq.el:
>> seq-find and seq-position.
>>
>> While I can live with it, I find it unsatisfactory: these seem
>> completely arbitrary since they're not in any obvious sense more "entry
>> points" than other functions in that library.
>
> Eli suggested this methodology as a way to use seq.el in pre-dumped
> files without pre-dumping seq.el in Emacs (and as a way to determine
> whether seq.el is really needed).  I suspect that we'll end up (after a
> year or two) having all the functions in seq.el ;;;###autoloaded.

Sorry, I've added two more autoloads to seq.el required by the new command
in the preloaded tab-bar.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-26 22:17   ` Juri Linkov
@ 2019-10-27  4:49     ` Eli Zaretskii
  2019-10-27 17:26       ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2019-10-27  4:49 UTC (permalink / raw)
  To: Juri Linkov; +Cc: larsi, monnier, emacs-devel

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 27 Oct 2019 01:17:17 +0300
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Sorry, I've added two more autoloads to seq.el required by the new command
> in the preloaded tab-bar.

That's okay, nothing to be sorry about.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-27  4:49     ` Eli Zaretskii
@ 2019-10-27 17:26       ` Stefan Monnier
  2019-10-27 17:52         ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2019-10-27 17:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, emacs-devel, Juri Linkov

>> Sorry, I've added two more autoloads to seq.el required by the new command
>> in the preloaded tab-bar.
> That's okay, nothing to be sorry about.

Indeed.  It just shows there's a need to preload seq.el.
FWIW, I just changed the direction of dependency between seq.el and
cl-lib so we should now be able to preload seq.el without having to also
preload cl-lib (or anything else for that matter, AFAICT).


        Stefan




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Autloading seq.el functions
  2019-10-27 17:26       ` Stefan Monnier
@ 2019-10-27 17:52         ` Eli Zaretskii
  0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2019-10-27 17:52 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: larsi, emacs-devel, juri

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Juri Linkov <juri@linkov.net>,  larsi@gnus.org,  emacs-devel@gnu.org
> Date: Sun, 27 Oct 2019 13:26:01 -0400
> 
> >> Sorry, I've added two more autoloads to seq.el required by the new command
> >> in the preloaded tab-bar.
> > That's okay, nothing to be sorry about.
> 
> Indeed.  It just shows there's a need to preload seq.el.

No, it doesn't.  Preloading it will be needed if we use its functions
in every session, or close to that.  Just having to call one of its
functions when a specific command is invoked is not yet a reason good
enough to preload.  Emacs should not preload more than it absolutely
has to.



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-10-27 17:52 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-23 16:00 Autloading seq.el functions Stefan Monnier
2019-10-23 18:05 ` Eli Zaretskii
2019-10-24 11:43 ` Lars Ingebrigtsen
2019-10-26 22:17   ` Juri Linkov
2019-10-27  4:49     ` Eli Zaretskii
2019-10-27 17:26       ` Stefan Monnier
2019-10-27 17:52         ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).