unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefan@marxist.se>, Eli Zaretskii <eliz@gnu.org>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: [External] : Re: Lift {global,local}-key-binding to Lisp
Date: Thu, 21 Jan 2021 16:59:21 +0000	[thread overview]
Message-ID: <SA2PR10MB4474C10B6766E9FF6A8A653EF3A19@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <CADwFkmmgT0e2k0wGcxFLa0+hY0oYFOdUFxpRO5Cuu2AdwU+Nsw@mail.gmail.com>

> The important thing to note is that we have more people that know Lisp
> than we have that know (the Emacs dialect of) C.  This affects reading,
> debugging and modifying code.

Yes. But it's not only that more know Lisp.

1. Elisp is part of the Emacs UI.  It's an intimate
   part of using Emacs, for many users.  And it should
   be, for most.

2. Many users will not have downloaded and installed
   the C source code.  The Lisp code is included in
   prebuilt MS Windows binaries, as well it should be
   (see #1).

It should not be controversial that whatever can
reasonably be defined in Lisp, should be.  What's
"reasonable"?  Presumably most things that don't
touch toolkit, window manager, display, etc., and
that aren't performance critical.

The recent `length-<' etc. additions come to mind...

> For example, I have no doubt that you are intimately familiar with gdb,
> but you will find that many Emacs users will be much more familiar with
> edebug.  In fact, you can safely assume that almost anyone looking to
> contribute to Emacs will be very familiar with Emacs Lisp, but you can
> in my opinion _not_ assume that they will be familiar with C.

Yup.  No-brainer, IMHO.

> >> Of course, any such change taken in isolation will look like something
> >> we could also live without, but many such incremental improvements over
> >> time will start to make a difference for the better.  Clean and
> >> maintainable code is a good thing, and Lisp is better for that than C.
> >
> > I disagree, so let's please not do that unless we also add some
> > significant improvements or simplification.
> 
> I admit this response surprised me.  As far as I'm concerned, these
> arguments (functional programming, memory safety, etc.) were settled a
> long time ago.  But I suppose we can agree to disagree on this point.

Good luck, Stefan K.

  reply	other threads:[~2021-01-21 16:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 19:26 Lift {global,local}-key-binding to Lisp Eli Zaretskii
2021-01-14 19:24 ` Stefan Kangas
2021-01-14 20:10   ` Eli Zaretskii
2021-01-14 20:24     ` Eli Zaretskii
2021-01-15  1:58     ` Leo Liu
2021-01-15  4:16     ` Óscar Fuentes
2021-01-15  7:42       ` Eli Zaretskii
2021-01-21 16:03     ` Stefan Kangas
2021-01-21 16:59       ` Drew Adams [this message]
2021-01-21 17:50         ` [External] : " Dmitry Gutov
2021-01-21 18:16           ` Drew Adams
2021-01-21 18:58             ` Dmitry Gutov
2021-01-21 19:59       ` Eli Zaretskii
2021-01-14 21:03   ` Andrea Corallo via Emacs development discussions.
2021-01-15  7:45     ` Eli Zaretskii
2021-01-15 12:09 ` Dmitry Gutov
2021-01-15 12:18   ` Eli Zaretskii
2021-01-15 13:24     ` Dmitry Gutov
2021-01-15 13:45       ` Eli Zaretskii
2021-01-15 18:09         ` Dmitry Gutov
2021-01-17 14:27           ` Christopher Miles
2021-01-15 18:03       ` Drew Adams
2021-01-16  0:51   ` Leo Liu
2021-01-17 14:33     ` Christopher Miles
2021-01-17 15:08       ` Eli Zaretskii
2021-01-18  3:29         ` Christopher Miles
2021-01-18 16:43           ` Eli Zaretskii
2021-01-17 16:10       ` Basil L. Contovounesios

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=SA2PR10MB4474C10B6766E9FF6A8A653EF3A19@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --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).