unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: stefan@marxist.se, emacs-devel@gnu.org
Subject: Re: Preloading seq.el
Date: Thu, 29 Aug 2019 17:35:06 +0200	[thread overview]
Message-ID: <874l20j87p.fsf@gnus.org> (raw)
In-Reply-To: <834l20athk.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 29 Aug 2019 18:20:23 +0300")

Eli Zaretskii <eliz@gnu.org> writes:

> The way to hell is paced one step at a time.  Those 3MB were not all
> added in one go, they were added one file at a time.  So we need to
> examine every single file we want to add and decide on a case by case
> basis, otherwise we will get 6MB instead of 3MB faster than you can
> say "make autoloads".

Indeed.  But in my experience, I find myself using seq/cl-lib functions
in the pre-loaded Emacs files (because I just don't have a very good
overview of which ones are preloaded and which ones aren't), and then
having to rewrite the code to avoid using those functions when it turns
out that Emacs doesn't build.

(Sometimes after pushing, unfortunately.)

So I'm saying that, in my opinion, seq/cl-lib would be good additions to
the set of preloaded packages in Emacs.  They would make the code in
those files better, and may well make them smaller in the long run
because we wouldn't have to basically open-code the seq/cl-lib
functionality, which I find myself doing now.

(But if you're OK with ;;;###autoload any time we use seq/cl-lib in
those files, then that's also fine with me, but I think that in the long
run, it's preferable to just preload them, because I think we're going
to end up with 80% of them ;;;###autoloaded.)

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



  reply	other threads:[~2019-08-29 15:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29 12:21 Preloading seq.el Stefan Kangas
2019-08-29 12:30 ` Lars Ingebrigtsen
2019-08-29 12:47   ` Eli Zaretskii
2019-08-29 12:50     ` Lars Ingebrigtsen
2019-08-29 14:59       ` Eli Zaretskii
2019-08-29 15:15         ` Lars Ingebrigtsen
2019-08-29 15:20           ` Eli Zaretskii
2019-08-29 15:35             ` Lars Ingebrigtsen [this message]
2019-08-29 18:41               ` Eli Zaretskii
2019-08-29 18:43                 ` Lars Ingebrigtsen
2019-08-29 21:44                   ` Stefan Monnier
2019-08-29 15:20   ` Stefan Monnier
2019-08-29 12:44 ` Eli Zaretskii
2019-08-31 12:33 ` Zhu Zihao
2019-08-31 12:38   ` Eli Zaretskii
2019-09-06  0:49     ` Juanma Barranquero
2019-09-06  7:12       ` Eli Zaretskii
2019-09-06  7:46         ` Robert Pluim
2019-09-06  8:23           ` Eli Zaretskii
2019-09-06 11:27         ` Juanma Barranquero

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874l20j87p.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).