Re: Lisp files that load cl-lib in problematical ways

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 20 Oct 2023 05:02:14 +0200
> 
> Eli Zaretskii wrote:
> 
> >> So what does it matter if it is "purged" from one or
> >> several of these levels? What gain is there if that
> >> is achieved?
> >
> > It matters to us because we decided long ago to avoid
> > loading cl-lib at runtime in vanilla Emacs.
> 
> But as we have seen in practice it _is_ loaded, be it by the
> debugger, by native compilation, or any other package or piece
> of Elisp that uses it, or uses something else that is using
> it. It is all interconnected, and because it is used so much
> already, using Emacs in practice implies having cl-lib loaded
> at run time.

It is okay for cl-lib to be loaded when packages that use it are
loaded.  The same happens with gazillion other packages in Emacs; for
example, try loading Gnus or Org or Eshell, and see how much stuff
unrelated to these packages per se gets loaded as result, because
those packages need some non-default infrastructure.

What matters to us is that this unnecessary stuff is not loaded in
"emacs -Q", i.e. is not dumped and preloaded into the bare
uncustomized Emacs session.  This lets users start from the leanest
possible Emacs, then load what they need, without being "punished" by
loads of stuff they never need or want.

For Emacs to preload unnecessary stuff is unclean, and we try to avoid
that uncleanliness.

> > There are several good reasons: bloat, unnecessary namespace
> > pollution, etc.
> 
> People use it because it is useful: there is `cl-loop',
> `cl-incf', `cl-decf', `cl-pushnew' and many others examples of
> that. Those are not complicated to use, they are all prefixed
> with cl- (as we see) and have good docstrings.

This is not relevant to the issue at hand.

> > But all this is not really relevant for the code that you
> > (or any one of us) write for their own personal use, it is
> > only relevant to code contributed to Emacs.
> 
> But we don't know what people who are starting to write Elisp
> today for their personal use go on to contribute to Emacs
> packages that make it to the ELPAs, or core Emacs for that
> matter.

That's okay, they will learn it on-the-fly, from review comments to
their contributions, like with the rest of our coding conventions,
which are usually not clear to new contributors when they first
contribute.

> You, and everyone else writing Elisp for that matter, are of
> coures equally permitted not to use it, if they consider it
> harmful, it just shouldn't be labeled detrimental as a policy
> with really no good arguments supporting that claim that we
> have seen thus far at least.

See above: this is not relevant to the issue at hand.