[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: |
Mon, 23 Oct 2023 14:18:01 +0300 |
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 22 Oct 2023 22:08:55 -0400
>
> > abbrev.el:2
>
> A generally useful minor mode as abbrev.el should not load cl-lib.
> Why does it? I investigated.
>
> abbrev--check-chars uses the macro cl-pushnew. Generally we
> arrange for cl- macros not to load cl-lib. But cl-pushnew
> is _defined_ in cl-lib. It ought to be defined with and like
> other cl- macros that are meant for users to use.
It would not have helped to define cl-pushnew on cl-macs, because
cl-pushnew calls cl-adjoin, which is a function defined on cl-lib. So
basically cl-pushnew is a (rather thin) wrapper around cl-adjoin, and
thus it is correctly defined on the same file where cl-adjoin is
defined. I see no problem here.
> I investigated byte-run.el. I don't think it uses any cl- facility.
> Rather, it declares a let-variable whose name starts with cl-.
byte-run.el indeed doesn't need cl-lib, and loading byte-run.elc
doesn't load cl-lib. So I see no problem here, either. IOW, this is
a false positive due to the naïve search pattern used to detect this.
> I think that if we investigate the other general-purpose packages
> in the list you posted (I copied it below), we wlll find many such bugs that
> got in because developers were not on guard against them.
I very much doubt that we will find many such bugs, because we
actually pay close attention to these aspects as part of our patch
review process. But, of course, there could be places we missed, so
if someone finds them, please do report them and/or propose patches to
fix them.
> Once we fix them all, how about if we add a regression test
> to verify that various packages anyone might load at any time
> do not use cl-lib. With that, bugs like this would get caught
> right away.
It isn't easy to write such a test, since our test suite
infrastructure, ert.el, itself uses cl-lib extensively. But if
someone can come up with a test, please do submit it, and TIA.
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- 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, Emanuel Berg, 2023/10/23
- Re: Lisp files that load cl-lib in problematical ways, Björn Bidar, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/22
- Re: Lisp files that load cl-lib in problematical ways,
Eli Zaretskii <=
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Stefan Kangas, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Gerd Möllmann, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/25
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Adam Porter, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Dmitry Gutov, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Alan Mackenzie, 2023/10/26
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/26