From: Drew Adams <drew.adams@oracle.com>
To: Oleh Krehel <ohwoeowho@gmail.com>, Kaushal Modi <kaushal.modi@gmail.com>
Cc: Michael Albinus <michael.albinus@gmx.de>,
Stefan Monnier <monnier@iro.umontreal.ca>,
Emacs developers <emacs-devel@gnu.org>
Subject: RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
Date: Mon, 22 Feb 2016 15:15:16 -0800 (PST) [thread overview]
Message-ID: <bf6c5d0f-616b-4818-8538-f77c4fc8d77f@default> (raw)
In-Reply-To: <87r3g4js64.fsf@gmail.com>
> > +1
> >
> > I wholeheartedly agree to that.
>
> +1 from me as well. I recall recently Richard proposed that we vote on
> some new isearch feature. Should we vote on renaming `cl-caddr' ->
> `caddr' as well?
>
> Here's a list of `cl-' stuff that I like to use, which I think wouldn't
> bring confusion without a `cl-' prefix: `cl-find-if',
> `cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr',
> `cl-rotatef', `cl-destructuring-bind'.
>
> I realize there are prefix-less aliases for most of these functions.
> But I'm not sure how long they're staying. And if they are staying
> indefinitely, is there a reason to use `cl-' prefix? I made a switch to
> the prefix some time ago when the unprefixed macros became no longer
> syntax-highlighted. But now since recently all macros are syntax
> highlighted, no matter where they come from.
I understand that we like using library prefixes (I respect that),
hence the use of `cl-'. But there is plenty in Emacs that is just
plain _Lisp_, and which is not different between Common Lisp and
anything else that Emacs has. Emacs Lisp has just as much a right
to these Lisp names as any other Lisp.
We don't say `subr-rplacd' just because `rplacd' is defined in `subr.el'.
And we have plenty of functions and macros that are not found in other
Lisps. Many of those too are in files that are not considered to be
foreign libraries but, like `subr.el', are simply part of the Emacs-Lisp
language.
We don't say `simp-goto-line' just because `goto-line' is defined in
`simple.el'. And we don't say `diraux-dired-do-chmod' just because
`dired-do-chmod' is defined in `dired-aux.el'.
Why should we act differently when it comes to things like `caddr'?
Regardless of what file they are in, and whether that file is loaded
by default (like `simple.el' and `subr.el') or only on demand (like
`dired-aux.el), I see no good reason for such things to be plastered
over with a `cl-' prefix.
In a way this is a minor, bike-shed point. And in a way it is
anything but bike-shedding.
To me, it is just common sense to use widespread, longstanding Lisp
names as is, without embellishment. Unless, that is, there is an
Emacs-Lisp version that already has the unembellished name and is
different.
In the relatively few cases where Emacs Lisp has its own, different
thing that has a widespread Lisp name, using the `cl-' prefix for
the Common Lisp emulation is appropriate. And that makes the
difference stand out: This thingy with the `cl-' prefix is different
from the similarly named thingy without that prefix.
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.
If it's just because such things are in a `cl*.el' file then I think
we're missing the point of such a prefix. It should be reserved for
Common Lisp emulation, nothing more or less.
next prev parent reply other threads:[~2016-02-22 23:15 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160222175244.30186.2617@vcs.savannah.gnu.org>
[not found] ` <E1aXuf6-0007rW-6h@vcs.savannah.gnu.org>
2016-02-22 18:51 ` [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification Stefan Monnier
2016-02-22 20:41 ` Michael Albinus
2016-02-22 20:49 ` Dmitry Gutov
2016-02-22 20:50 ` Stefan Monnier
2016-02-22 21:07 ` Michael Albinus
2016-02-22 21:19 ` Stefan Monnier
2016-02-22 22:48 ` Michael Albinus
2016-02-22 23:22 ` Stefan Monnier
2016-02-22 21:39 ` Drew Adams
2016-02-22 21:42 ` Kaushal Modi
2016-02-22 22:28 ` Oleh Krehel
2016-02-22 23:15 ` Drew Adams [this message]
2016-02-23 1:05 ` John Wiegley
2016-02-23 1:58 ` Lars Ingebrigtsen
2016-02-23 2:11 ` Stefan Monnier
2016-02-23 16:41 ` John Wiegley
2016-02-23 16:50 ` Stefan Monnier
2016-02-23 17:11 ` Drew Adams
2016-02-23 22:48 ` John Wiegley
2016-02-24 1:56 ` Stefan Monnier
2016-02-24 2:00 ` John Wiegley
2016-02-24 2:50 ` Drew Adams
2016-02-24 2:17 ` Lars Ingebrigtsen
2016-02-24 3:32 ` Stefan Monnier
2016-02-24 3:52 ` Lars Ingebrigtsen
2016-02-24 3:53 ` Lars Ingebrigtsen
2016-02-24 4:09 ` Stefan Monnier
2016-02-24 4:23 ` Lars Ingebrigtsen
2016-02-24 15:18 ` Nicolas Richard
2016-02-24 15:33 ` Clément Pit--Claudel
2016-02-24 12:21 ` Dmitry Gutov
2016-02-24 15:29 ` Nicolas Richard
2016-02-24 16:51 ` Drew Adams
2016-02-24 4:08 ` Clément Pit--Claudel
2016-02-24 10:02 ` Stephen Berman
2016-02-29 6:24 ` Drew Adams
2016-02-29 7:06 ` John Wiegley
2016-02-29 15:41 ` Drew Adams
2016-02-29 19:53 ` Joost Kremers
2016-03-01 16:53 ` Richard Stallman
2016-02-29 17:15 ` Stefan Monnier
2016-02-29 18:11 ` Drew Adams
2016-02-29 18:47 ` John Wiegley
2016-02-29 19:28 ` Drew Adams
2016-02-29 20:05 ` Stefan Monnier
2016-02-29 21:19 ` Drew Adams
2016-02-29 21:57 ` Stefan Monnier
2016-02-29 22:19 ` Drew Adams
2016-03-01 16:53 ` Richard Stallman
2016-03-01 20:09 ` John Wiegley
2016-02-23 17:45 ` Richard Stallman
[not found] ` <<87r3g4js64.fsf@gmail.com>
[not found] ` <<E1aYH1b-0006nO-9u@fencepost.gnu.org>
2016-02-23 18:09 ` Drew Adams
2016-02-24 13:41 ` Richard Stallman
2016-02-22 23:29 ` Stefan Monnier
2016-02-22 23:50 ` Drew Adams
2016-02-23 17:45 ` Richard Stallman
[not found] ` <<87egc4v4hs.fsf@gmx.de>
[not found] ` <<8bd4ec21-1306-41bf-aca7-5571a3014337@default>
[not found] ` <<E1aYH1M-0006ia-SR@fencepost.gnu.org>
2016-02-23 18:05 ` Drew Adams
2016-02-24 13:41 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bf6c5d0f-616b-4818-8538-f77c4fc8d77f@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=kaushal.modi@gmail.com \
--cc=michael.albinus@gmx.de \
--cc=monnier@iro.umontreal.ca \
--cc=ohwoeowho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).