[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lisp files that load cl-lib in problematical ways
From: |
Alan Mackenzie |
Subject: |
Re: Lisp files that load cl-lib in problematical ways |
Date: |
Thu, 19 Oct 2023 13:28:28 +0000 |
Hello, Eli.
On Thu, Oct 19, 2023 at 15:55:34 +0300, Eli Zaretskii wrote:
> > Date: Thu, 19 Oct 2023 12:34:42 +0000
> > Cc: rms@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > So, I counted all the occurrences of "cl-" not inside an
> > eval-when-compile, by piping all the dumped .el files through the
> > following script:
[ .... ]
> > and got the following results:
> > abbrev.el:2
[ .... ]
> > vc/vc-hooks.el:1
> If the above is correct, then how do you explain that in "emacs -Q" I
> don't see the cl-lib feature present?
Because the files that use cl- don't have a (require 'cl-lib) in them.
Quite a lot of the function calls are things like cl-assert, cl-incf, or
cl-defgeneric, which won't cause the loading of cl- until they are
actually run.
> My conclusion is that your program has a bug.
Maybe, but there are definitely run time uses of cl- in our dumped .el
files, such as a cl-incf in font-lock.el which creates the gradually
increasing row of dots which are displayed for large files (or, at least,
used to be).
> > That may not be 541 occurrences, but it's still 239. Incidentally, when
> > I start emacs -Q, cl-lib isn't yet loaded for me, either.
> Exactly. How come, if all of the above-mentioned files load it?
See above.
> > > We cannot possibly expect people to contribute code if we force them
> > > not to use the macros they are used to. If cl-lib is not loaded as
> > > result, that is good enough for us, I think.
> > We "force" them to use Emacs Lisp, but they still contribute. The
> > problem is that use of cl- makes maintenance of other people's code much
> > harder, at least for me. I'm sure I'm not alone.
> I'm sorry, but the above is how I feel we should treat our
> contributors, if we want to keep the existing ones and attract new
> ones.
I'm not urging you to change anything; merely expressing regret at the
existing state of affairs, and possibly inviting contributors in general
to use cl-lib a little less.
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Lisp files that load cl-lib in problematical ways, (continued)
- 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, Eli Zaretskii, 2023/10/23
- Message not available
- Re: Lisp files that load cl-lib in problematical ways, Emanuel Berg, 2023/10/22
- 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, 2023/10/22
- 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, Alan Mackenzie, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways,
Alan Mackenzie <=
- Re: Lisp files that load cl-lib in problematical ways, Eli Zaretskii, 2023/10/19
- Re: Lisp files that load cl-lib in problematical ways, Michael Heerdegen, 2023/10/20
- 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