Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Stefan Monnier]

>> As you know, there are other options.  E.g. to distribute that other
>> package (cl-lib) along with yours.  Or to distribute your package via
>> a system which will take care of "search for and download" (e.g. ELPA).
> The first would cause irritation to the user.

Hmm... sorry, I don't see why that would cause irritation.
AFAICT the user would be blissfully unaware.  I doubt many of your users
would notice an additional 13KB file in your package.

> The second is simply not the way CC Mode is distributed.

I understand you want to support users of Emacsen that don't have
package.el, and that makes sense, indeed.  I mentioned it, because
I think it should be fairly easy to also distribute CC-mode via GNU
ELPA with very little extra work (the package would be built directly
from emacs.git, like we do for python.el, soap-client, and a few
more).

But yes, whether we do that or not doesn't make a difference for the
case of users of Emacsen without package.el (i.e. Emacs-23 and XEmacs).

>> Bundling cl-lib with your "manually installed" cc-mode package should be
>> pretty easy.  I'd be all too happy to help you with it, if that can sway you.
> Talk about taking a sledgehammer to crack a nut!

I agree that if you look at it as "adding a 13KB file" vs "add a few
(defmacro ... (if (eq c--cl-library ...)))", the choice may sound like
a sledgehammer, but the way I look at it, cl-lib.el is a file that's
already written and hasn't needed any maintenance since Feb-2014,
so you can take it as a black box.

>> Ah, yes, that discussion.  It's hard to please everyone.
> No, not really.  Leaving the traditional names in place, producing no
> compiler warnings, would have pleased more than what was done.

I see we agree ("more than" is not "everyone").

> Funnily enough, I don't remember any negotiation, or even discussion
> about the matter on emacs-devel before this change happened.  The extra
> macros in CC Mode are one of the consequences.  I would really rather
> not have had to spend time on this.

IIUC, the introduction of cl-lib is the result of the thread that
started with
https://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00175.html
This other thread is also related:
https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00245.html

But it is also the result of many earlier discussions asking for the
same thing.  Again and again, people asked to get access to all of CL's
functionality in Emacs (i.e. including CL's functions at runtime) and it's
always been rejected until we came up with cl-lib (and took advantage of
it to move several CL features, like setf, into core at the same time).

I have no intention to claim it's the perfect solution.  I'm pretty sure
it was noone's favorite solution, but my impression after 5 years is
that most people think it was an improvement (in large part thanks to
the cl-lib.el forward compatibility library which significantly eases up
the transition, although you don't want to use).


        Stefan