[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lisp files that load cl-lib in problematical ways
From: |
Emanuel Berg |
Subject: |
Re: Lisp files that load cl-lib in problematical ways |
Date: |
Tue, 24 Oct 2023 14:43:48 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Eli Zaretskii wrote:
>> About how much memory are we talking here? All this sounds
>> like talk about micro optimizations.
>
> If we ignore such "micro optimizations", we will quickly
> bloat Emacs, since those small amounts add up. We have a lot
> of relatively small potential additions that we make a point
> of not adding, because if we decide adding one is okay, then
> why not add all the rest? We don't add such stuff to subr.el
> or to simple.el or to files.el, and keep them separate,
> precisely because adding them all will not be insignificant.
>
> The only way of keeping this kind of bloat at bay is to
> resist adding anything, no matter how small, because, like
> I said, it's a slippery slope.
While I agree one shouldn't ignore micro optimizations in
general, you keep refering to useful Elisp as bloat. That is
disrespectful and also not true, it is useful code, and where
it is or isn't added or loaded doesn't change it into
something it isn't.
Also, instead of the general "slippery slope" model of thought
and offered explanation, it is better to either have a clear
policy "we add stuff that [...]". Then one can say "we don't
intend to include some-package.el because it doesn't fall
under our policy what stuff to add, because it is [...] and
the policy is [...]".
If one cannot formulate a general policy it will instead have
to be dealt with on a case-by-case basis. But then one would
like to hear the arguments for each such case suggested, and
in terms of what that package brings (or lacks) and where it
is suggested to be added, not that you want to keep "this kind
of bloat at bay".
--
underground experts united
https://dataswamp.org/~incal
- 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/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
- 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, Björn Bidar, 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,
Emanuel Berg <=
- 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, Emanuel Berg, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Björn Bidar, 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, Emanuel Berg, 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, Richard Stallman, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/27
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Björn Bidar, 2023/10/19