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, 14 Jan 2021 13:24:10 -0600	[thread overview]
Message-ID: <CADwFkm=M0dWgD2g4JXL4rOj1=-MTUF9aPV1=5cCF5OgDAACzGg@mail.gmail.com> (raw)
In-Reply-To: <83zh1cbpua.fsf@gnu.org>

Eli Zaretskii <eliz@gnu.org> writes:

> Stefan, why are we moving these and other functions to Lisp?  Are
> there any advantages to moving them?

AFAIK, the main reason to have things in C is if there is a performance
benefit to doing so.  The reason for this change (and the previous
commit) is simple: I noticed that there existed a handful of functions
in keymap.c that does not see any such performance benefit.

There is IMO no reason not to reduce the number of C primitives where
possible.  Lisp is a superior language to C, for all the usual reasons.
It is also better supported in Emacs itself in terms of debugging,
advising, etc.

As for future plans:

- I have a patch for `describe-buffer-bindings' that I intend to finish
  up soon (after fixing an unrelated performance regression bug).  This
  has more obvious benefits than the trivial case discussed here.

- There are a handful other functions in keymap.c that could usefully be
  moved to Lisp.

> And why don't we discuss such changes before making them?

If you prefer, I'm of course happy to send any patch for review before I
make any more changes like this.  I had already intended to do so for
the somewhat more complex case of `describe-buffer-bindings', but did
not realize it would be necessary for these trivial ones.

> In general, unless we get some significant gains, I'd prefer not to
> move around code just to move it.

It is hard to disagree with this point, in general.  But that was not
the reason for moving it, see above.

> If nothing else, it makes it harder for people who, like me, are
> familiar with the original code, to find stuff, because suddenly it
> isn't where it used to be.

The functions we are discussing here are rarely used, AFAICT, so I'm not
sure I understand this point.  Well, frankly I don't understand it even
if they were used a lot.

(FWIW, I use `xref-find-definitions' or `describe-function' to avoid
having to memorize the locations of functions.)

> It's a needless churn, and I ask myself what do we gain in
> return?

Emacs will be around in 40-50 years still, and we should maintain it
with that in mind.  Every time we make code more readable and
maintainable, we make our life easier in the long run.  Yes, at the
minor price of actually making the change.

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.



  reply	other threads:[~2021-01-14 19:24 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 [this message]
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       ` [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='CADwFkm=M0dWgD2g4JXL4rOj1=-MTUF9aPV1=5cCF5OgDAACzGg@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).