[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: |
Wed, 25 Oct 2023 15:15:42 +0300 |
> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Tue, 24 Oct 2023 22:44:49 -0400
>
> > frameset.el makes moderately heavy use of cl-lib, including at least two
> > externally visible cl-defun's where keyword parameters are used. It
> > would be a lot of work to replace cl-lib in this file
>
> cl-defun is a macro; using it ought to work without causing cl-lib to
> be loaded. So if frameset.el does load cl-lib, the next question is
> what it is in the file that actually does so.
It uses several cl-lib functions: cl-every, cl-find-if,
cl-delete-if-not, and some others.
This code was written before we had seq.el, which is nowadays
preloaded. So I guess we could rewrite frameset.el to use seq.el
instead (and a few cl-macs macros it uses). If someone wants to work
on this, please do.
In any case, I see no reason to continue asking this kind of questions
on the list. Each such question can be easily answered by using
M-. and "C-h f", so anyone who is interested in understanding why a
given Lisp package loads cl-lib already has the answers at their
fingertips. There's no reason to ask questions on the list that can
be easily answered in a few seconds.
I also very much doubt that what people will find by using "C-h f" and
M-. will be "bugs", since such bugs would have been found long ago.
It bothers the heck out of me to hear assessments like that which
clearly hint that the quality of our code is deemed to be so low; it
is not.
And again, let's not keep this discussion, as it just wastes bandwidth
and energy on something that can be found within seconds by anyone who
wants to know.
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- Re: Lisp files that load cl-lib in problematical ways, Richard Stallman, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Alan Mackenzie, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Gerd Möllmann, 2023/10/21
- RE: [External] : Re: Lisp files that load cl-lib in problematical ways, Drew Adams, 2023/10/21
- 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, Eli Zaretskii, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Alan Mackenzie, 2023/10/21
- Re: Lisp files that load cl-lib in problematical ways, Gerd Möllmann, 2023/10/21
- 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,
Eli Zaretskii <=
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/25
- 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, Alan Mackenzie, 2023/10/21
- 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, Alan Mackenzie, 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, Richard Stallman, 2023/10/24
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 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