Re: Lift {global,local}-key-binding to Lisp

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 14 Jan 2021 13:24:10 -0600
> Cc: emacs-devel@gnu.org
> 
> AFAIK, the main reason to have things in C is if there is a performance
> benefit to doing so.

That's not the only reason, but I think for code that exists for a
long time the reasons are no longer relevant.  The code was written
like that back then, and we should only change it if we have a good
reason.  I don't see such a good reason in this case, and without
that such changes are a needless churn with no benefits.

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

If this means you'd want to move to Lisp every piece of C that doesn't
need to be fast, then I don't agree with that, sorry.  Surely, we have
better things to do with our time and resources than move code from
one language and file to another without changing anything in
functionality.  Our main task here is to develop and extend Emacs by
improving existing features and adding new ones; let's invest our
efforts mainly in those directions.  Cleanup is only secondary, and
these particular changes cannot even be qualified as cleanup, as the
original code was as clean as it's now after being rewritten almost
verbatim in Lisp.

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

The reason not to do so is what I wrote in my previous message: it
gets in the way of finding the code which does something when you need
it, whether to recall how it works or consider some changes there.
Whether we move to Lisp, change the names, or do something else which
doesn't affect how the code works, we make it harder to find the code
without grepping or using M-., and that slows me down, sometimes
considerably so.

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

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

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.

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

If it's for the same reasons as you described above, then let's please
not do that.  I'm not interested in moving as much of keymap.c to Lisp
as possible if the motivation is that just rewriting in Lisp makes it
somehow better; I disagree with that motivation.

> > 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 meant discuss plans such as this one, not necessarily each and every
changeset.  If the general idea behind some series of changes is
agreed upon, I don't think posting each changeset will be necessary.

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

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.  That
gets in the way when I need to find some code quickly without
necessarily knowing the exact names of functions and variables -- and
I need that a lot, whether to answer a question, consider some
possible reasons for a bug report, etc.

Besides, when you move stuff to Lisp, it loses one of the two
identifiers by which it is known: only the Lisp identifier is left,
the C identifier is removed.  So even M-. will only help if you use
the Lisp identifier, which is another thing one has to remember or
guess when the old code is not there to be found.

And having code I'm familiar with disappear from where I used to find
it is a disorienting experience: I frequently begin to question my
memory regarding the name of the function or variable, or even that we
indeed have the code that I'm looking for, and it is generally an
annoyance and a slowdown.  Maybe you are not yet familiar with the
code enough to be affected by these changes, but I am.  Please respect
my workflows.

I hope you now understand better why these changes are an annoyance.
If they are done to gain some new features or extend existing ones,
then these annoyances can be justified.  But we gained nothing like
that in this case.  You are not the only one who works with this code
base.

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

I don't really see how moving stuff to Lisp in these cases makes the
code more readable or maintainable.  You basically wrote the same code
in Lisp as it was in C.

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

TIA