[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.
Date: Mon, 26 Jun 2017 18:20:37 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Stefan.

On Mon, Jun 26, 2017 at 13:56:46 -0400, Stefan Monnier wrote:
> > cl-lib doesn't exist in those older Emacsen, neither does it exist in
> > XEmacs.  So doing what you suggest isn't a sensible thing to do.

> Lots of Emacs packages rely on cl-lib while supporting older Emacsen
> as well.  There are trade-offs, admittedly, but calling it "not
> sensible" is like me saying that your choice is ridiculous.

> My question was specifically to understand which part of the trade-offs
> made you choose one option over the other.

When a package relies on another package which is not part of the user's
Emacs, that forces that user either to search for and download that
other package, or to give up using the first package.  Both options are
likely to cause irritation and anger.

Doing so is unacceptable, IMAO, because it transfers effort from the
maintainer to the user.  The maintainer should do everything sensible to
smooth the way for his users.

> >> That would make you free to use any cl-lib functions and macros
> >> without having to add matching c--* macros.
> > The macros are necessitated by, amongst other things, name changes in
> > functions, some of which have had traditionally approved names for
> > decades.  (I have a copy of the Lisp Machine Manual from the 1980s to
> > back this up.)

> Many of your c--* macros are there to choose between the `cl` name or
> the `cl-lib` name, and every new macro/function you want to use from
> cl/cl-lib will require another one of those macros.

Yes.  One way to reduce this burden would be to make the traditional
names of these functions, without the "cl-" prefix, of equal status to
those with the prefix.

> Using cl-lib unconditionally would eliminate this need.

At great cost, as outlined above.

>         Stefan

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]