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?
>
> Loading cl.el modifies the observable behavior of dolist.

Yes, such is legacy.  See what I wrote about needing to fix
such problems (name clashes).

The fact that plain Emacs `dolist' is massaged to make it
DTRT for cl.el under that same name is wrong.  And then
cl-macs.el leverages that advice for `cl-dolist'.

The Emacs emulation of Common-Lisp `dolist' should be called
(only) `cl-dolist' - or else the Emacs thing by that name
should be renamed to something else.

Emacs has generally opted to co-opt some names for its own
version of a behavior, instead of giving the Emacs version
a different name.  Because of that we should not allow a
Common-Lisp emulation of such a thing use the same name.
It should use the `cl-' prefix, since the unprefixed name
is already taken.

Aliasing (or doing something that has the same effect, as
for `dolist') the plain name to the name with prefix `cl-'
is the wrong thing to do, in such cases.  We should alias
to remove prefix `cl-' only when the result is not a name
clash.


But again, this bug report is about unnecessarily
autoloading `cl-extra.el'.  It is not about `cl.el'.