unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Lift {global,local}-key-binding to Lisp
Date: Thu, 21 Jan 2021 10:03:28 -0600	[thread overview]
Message-ID: <CADwFkmmgT0e2k0wGcxFLa0+hY0oYFOdUFxpRO5Cuu2AdwU+Nsw@mail.gmail.com> (raw)
In-Reply-To: <83lfcvb7pj.fsf@gnu.org>

(Sorry for the late reply, I have been swamped with work.)

Eli Zaretskii <eliz@gnu.org> writes:

> If this means you'd want to move to Lisp every piece of C that doesn't
> need to be fast,

No, I have not suggested any such thing.  I said that there were a few
functions in keymap.c that I think we could usefully move to Lisp.

> (I disagree with your assertions about language quality and debugging
> support, but I don't think this is relevant to the issue at hand
> anyway, so let's drop this tangent.)

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.

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.

> I'd like to discuss those benefits as soon as possible, please,
> preferably before you have invested a significant effort into coding
> and testing the changes.

OK, I will send the patch as soon as I can find some time.

> I look for the code I'm familiar with where I expect to find it.
> Sometimes I don't remember exactly the identifiers, I just know where
> I used to find code which handles some specific issue or solves some
> problem, so M-. is not necessarily going to help.  For example, it is
> quite reasonable to look for keymap stuff in keymap.c, but now that
> it's moved to subr.el, how can one possibly remember that? it could be
> in simple.el, for example, or in subr-x.el, or somewhere else.

This might be a case for creating a new file keymap.el or somesuch.  (In
general, our organization of code into files could be better -- we don't
need to put every defun and its grandmother into subr.el et al.)

>> 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.



  parent reply	other threads:[~2021-01-21 16:03 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 [this message]
2021-01-21 16:59       ` [External] : " Drew Adams
2021-01-21 17:50         ` 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=CADwFkmmgT0e2k0wGcxFLa0+hY0oYFOdUFxpRO5Cuu2AdwU+Nsw@mail.gmail.com \
    --to=stefan@marxist.se \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /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).