RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> >  Finally, to make things even more muddy, we have recently piled
> >  additional, non-Common Lisp stuff into the `cl-' namespace.
> >  What's that about?  That just confuses people.
> 
> > This particular problem was reported as bug #20056, which was
> > just closed today as "wont-fix".
> 
> Daniel wrote:
> 
> > I think cl-lib has long ago stopped being an emulation of common
> > lisp. Now, it's a CL-*inspired* utility library. I doubt that 
> > there's a risk of real harmful confusion between this library
> > and actual Common Lisp.

Not so long ago, actually.  And unless there is an intention for
it to be for Common Lisp emulation, people will likely continue
to stick any old thing in there that has nothing to do with
Common Lisp.  Unless, of course, there is some other criterion
for inclusion there.  Is there?

> I agree with Daniel. cl-lib.el is an Emacs Lisp library that makes
> certain Common Lisp work-alikes available. It doesn't need to be
> restricted to *only* providing functions also in Common Lisp.

So is there NO criterion for inclusion there?  Anything and
everything belongs there?  If it is no longer for emulating
Common Lisp constructs what is it for now?

> As long as what's in there has a cl- prefix, it is in the
> right place unless it clearly does not belong there.

What defines "clearly does not belong there?  It's apparently
not enough to exclude a function that it have nothing to do
with Common Lisp (or with implementing the CL emulations).

What are the clearly-does-not-belong-there criteria?

> If you don't like the non-CL functions, don't use them.

Dunno where that remark is coming from.  I have no problem with
non-CL Emacs functions.  The question is why give some of them
prefix `cl-' and put them in the CL libraries?

Inclusion there should be based on what?  The question is even
more for future inclusion than it is for moving such functions
out that are already there.