unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: "João Távora" <joaotavora@gmail.com>
Cc: Stefan Kangas <stefan@marxist.se>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	"49278@debbugs.gnu.org" <49278@debbugs.gnu.org>
Subject: bug#49278: [External] : bug#49278: 28.0.50; Lisp Mode is for Common Lisp
Date: Tue, 28 Sep 2021 02:17:48 +0000	[thread overview]
Message-ID: <SJ0PR10MB548861563E49803EC83B2EB5F3A89@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CALDnm51c2Ng2uYwuaAdcsU1bWiF8otsXVE0jVQ0A7NLa+wSc9Q@mail.gmail.com>

> > It matters, I think, if the mode is called "Lisp mode".
> 
> Yes, it's true.  The name is unfortunate.  There are many Lisps,
> but "Lisp mode" is designed to work with only one of them, Common
> Lisp.
> 
> Renaming the mode to clarify an option IMO.  Maybe, if it has no
> impacts.  _Then_ would you agree to "Common Lisp mode is for Common Lisp"?

Yes, but you really don't need my agreement on
any of this.  I wasn't even aware that lisp-mode
is only suitable for Common Lisp mode.  I think
you'll find that I never claimed that lisp-mode
is suitable for more than Common Lisp.  I asked
if folks were sure that it isn't.

The last time I used lisp-mode itself was probably
back in the 80s and 90s, when coding Common Lisp.

And lisp-mode was apparently always described
(perhaps inappropriately even from the beginning?)
as "for Lisps other than GNU Emacs Lisp".  I guess,
not having used it much recently, I just assumed
that description was apt at some level.

I don't really care how y'all resolve this.  I do
think that a misleading mode name is just about as
important as a misleading description - maybe more
so.  People see the mode name much more often than
they read a mode description.

A question that occurs to me, but I have no reason
to argue about it, is whether it would make sense
to move the specifically CL stuff from lisp-mode
to a cl-mode, which would inherit from a neutral
lisp-mode.  Perhaps that neutral code would serve
as ancestor also of the modes for Closure and
Scheme?  No idea whether any such factoring would
make sense.  Maybe there's so little in common
that a real (neutral) lisp-mode would make no sense.

Another question, in light of your endeavor: what
about lisp-interaction-mode?  Is that suitable for
more lisps than Elisp?  It has emacs-lisp-mode as
a parent, but it's called "lisp" interaction mode.
Is it suitable for Closure and Scheme?  If not,
should it too perhaps be renamed and redescribed?
(Part of its description is "Like Lisp mode
except...".)

Back in Emacs 20, lisp-interaction-mode was defined
in library lisp-mode.el, BTW.  Now it's defined in
elisp-mode.el.

(You might guess that I also don't use
lisp-interaction-mode.  I typically change the mode
of `*scratch*' to emacs-lisp-mode.)

> Everybody that codes Common Lisp knows it by 'lisp-mode' and there
> are many tools that use that name. Maybe we could make an alias?

There are various ways to rename.  A priori, I
don't care whether or how it's renamed.  I do
think that if lisp-mode is really common-lisp-mode,
and its name is throwing people off, then renaming
would make sense - other things being equal.  It's
those other things that might not all be so equal
that you'll likely want to weight.

Similarly, if lisp-interaction-mode is really
elisp-interaction-mode.  (I don't say that it is;
I don't know, and I don't care.)

> Anyway, just _because_ it happens to be called Lisp Mode, erroneously,
> doesn't make it suitable for more Lisps magically.

No, of course not.  Did something give you the
impression that I would think that?

 - Real Michael Jordan

  reply	other threads:[~2021-09-28  2:17 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 18:06 bug#49278: 28.0.50; Lisp Mode is for Common Lisp João Távora
2021-06-29 18:16 ` Eli Zaretskii
2021-06-29 18:25   ` João Távora
2021-06-30 12:35     ` Eli Zaretskii
2021-06-30 12:45       ` João Távora
2021-06-29 20:46   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-29 20:55     ` João Távora
2021-06-29 22:59       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-30 12:47         ` Eli Zaretskii
2021-06-30 12:37     ` Eli Zaretskii
2021-06-30 13:03       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-30 13:21         ` João Távora
2021-06-30 13:29         ` Eli Zaretskii
2021-06-30 13:32           ` João Távora
2021-06-30 13:51             ` Eli Zaretskii
2021-06-30 14:32               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-30 14:50                 ` João Távora
2021-06-30 15:54                   ` Eli Zaretskii
2021-06-30 16:02                     ` João Távora
2021-06-30 15:52                 ` Eli Zaretskii
2021-06-30 16:37                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-30 16:47                     ` Eli Zaretskii
2021-06-30 16:50                       ` João Távora
2021-06-30 16:55                         ` Eli Zaretskii
2021-06-30 16:58                           ` João Távora
2021-06-30 14:54               ` João Távora
2021-06-30 15:55                 ` Eli Zaretskii
2021-06-30 15:58                   ` João Távora
2021-06-30 16:49                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-06-30  3:50 ` Phil Hagelberg
2021-06-30  9:44   ` João Távora
2021-09-24 23:01 ` Stefan Kangas
2021-09-24 23:23   ` João Távora
2021-09-25  0:22     ` Stefan Kangas
2021-09-25  1:26       ` bug#49278: [External] : " Drew Adams
2021-09-25  1:35       ` Lars Ingebrigtsen
2021-09-25  6:42       ` Eli Zaretskii
2021-09-25  1:13     ` bug#49278: [External] : " Drew Adams
2021-09-25  9:02       ` João Távora
2021-09-25 16:03         ` Drew Adams
2021-09-25 16:43           ` Stefan Kangas
2021-09-25 17:24             ` Drew Adams
2021-09-27 20:10           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-27 22:05             ` Drew Adams
2021-09-27 22:25               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-27 23:24                 ` Drew Adams
2021-09-27 23:36                   ` João Távora
2021-09-28  2:17                     ` Drew Adams [this message]
2021-09-28  2:06                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-28  2:31                     ` Drew Adams
2021-09-28  2:52                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-27 14:48         ` Jean Louis

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=SJ0PR10MB548861563E49803EC83B2EB5F3A89@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=49278@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefan@marxist.se \
    /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).