[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lisp files that load cl-lib in problematical ways
From: |
Eli Zaretskii |
Subject: |
Re: Lisp files that load cl-lib in problematical ways |
Date: |
Tue, 24 Oct 2023 15:48:19 +0300 |
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, gregory@heytings.org, rms@gnu.org,
> emacs-devel@gnu.org
> Date: Tue, 24 Oct 2023 12:41:13 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > Sure, but that's rather subjective. One could also argue that it is a
> >> > good thing to have certain symbols available immediately, for example
> >> > because they are typically needed.
> >>
> >> Could it be customizeable somehow?
> >
> > What do you want to be customizable, and how?
>
> What I have in mind is a custom list of packages to be dumped.
You can easily edit lisp/loadup.el and add whatever you want. So this
possibility already exists.
> >> I have seen articles using portable dumper to pre-load more libraries,
> >> but it was rather cumbersome and fragile exercise. It might be of
> >> interest for people interested in reducing the startup time to have
> >> a command like M-x dump-emacs-using-already-loaded-built-in-libraries.
> >> That way, users can pre-load the libraries that will be loaded anyway.
> >
> > Isn't that already available using dump-emacs-portable? Or am I
> > missing something?
>
> (1) It does not work interactively.
Doesn't M-: work?
> (2) Even making it work non-interactively is not necessarily trivial.
> See
> https://archive.casouri.cat/note/2020/painless-transition-to-portable-dumper/index.html
These are bugs we still need to find and fix. But adding arbitrary
Lisp packages to loadup.el is also likely to cause bugs, since
dumping Emacs is a tricky business in any case.
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Gregory Heytings, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Stefan Kangas, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Po Lu, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Stefan Kangas, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways,
Eli Zaretskii <=
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Corwin Brust, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Andrea Corallo, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Ihor Radchenko, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Corwin Brust, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/24