bug#25627: 25.1; `help-make-xrefs' loads `cl-extra.el' now

[Drew Adams]

> > I thought that the point of creating `cl-lib.el' was to give people a
> > library of the most-used CL constructs and still let them avoid loading
> > all of `cl.el'.  If we are, in effect, loading `cl-extra.el' now nearly
> > by default then what's the point of separating out `cl-lib.el'?
> 
> AFAIK, the point of cl-lib is to have the CL constructs in a separate
> namespace, so that loading cl-lib doesn't change the semantics of
> existing code that might not expect it (unlike cl.el).

What part of `cl.el' changes the semantics of existing [non-cl.el]
code?  It too uses prefix `cl-', for exactly the reason of not
changing things.

OK, there are some aliases, such as `case' for `cl-case'.  But I
thought that such was the case only for situations where Emacs
without cl.el did not have such a function/macro/etc. - such as
`case'.

It is true that there is also stuff in cl.el that IMO does not
belong there, because it is not a Common-Lisp emulation.  Stuff
like `lexical-let'.  Such stuff should be elsewhere.

There is also stuff that was misguidely given the `cl-' prefix
which has no counterpart in Common Lisp.  (I've pointed that out
to emacs-devel, but no one seemed to care...)

It is also the case that there is stuff that has the same name
as Common Lisp stuff but which is a very poor emulation of it
and should not use the C-L name.  An example is `flet'.  This
is a really good example of something bad.  Its doc string even
tells you that if you want something closer to Common Lisp use
`cl-flet'.  Unlike, e.g., `case' and `cl-case', `flet' is not
an alias of `cl-flet' (nor should it be).

Aside from such messes (and there are a bunch), I think that
cl.el, like cl-lib.el, separates its stuff from non-cl.el
stuff in Emacs.  I don't think there are cases of changing
semantics.  (But if there are, those should be fixed.)

At any rate, this bug report is about `cl-extra.el'.  It has
long been considered, rightfully, as _extra_ stuff.  (And it
is not loaded by loading `cl.el'.)  If you take a look at what
is in it then I think you'll agree that it is hardly stuff that
needs to be loaded by default.

And when I say "loaded by default" I speak loosely, including
the case of a user using `C-h f' and - whoops! - suddenly
cl-extra gets loaded.  That should not happen.  And it certainly
should not happen just because someone wanted to use `cl-some'.
That use case is such a trivial one to code in other ways.  The
only reasons I can think of for someone using `cl-some' here are
ignorance (that it is defined in cl-extra.el, laziness, or
I-don't-care.

> This change was done by [1: 59b5723c9b], the commit message is a bit
> terse.  But it looks like the idea is to use `describe-symbol-backends'
> for this in order to make it extendable, specifically to let cl-extra
> add an entry for classes.

Yes, I see what `cl-some' is used for, here.  But even if one
wants to do what is done with `describe-symbol-backends' (which
IMO has  a bad name and whose addition didn't gain us anything,
but that's OK), there is no need to use `cl-some' to do it.
One can use `describe-symbol-backends' easily without `cl-some'
(as I know you realize).

> 1: 2015-07-07 02:14:16 -0400 59b5723c9b613f14cd60cd3239cfdbc0d2343b18
>   Add online-help support to describe types

To be clear, my objection is not to the change that makes use of
`describe-symbol-backends'.  It is to the gratuitous use of
`cl-some' which pulls in cl-extra by an autoload.  No need; not
good.