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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 21 Jan 2021 10:03:28 -0600
> Cc: emacs-devel@gnu.org
> 
> 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.
> [...]
> >> 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.

These high-level arguments completely miss the point, because the
disagreement is not on that level.  This isn't about which language is
better for implementing Emacs features, not at all.  But agreement
about that doesn't mean we should rewrite in Lisp every piece of C
code we have.  I tried to explain what are the practical aspects that
I think need to be considered in cases such as the one which started
this thread.  Your response completely ignores most of those points.

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

It's okay to send a ready patch, but my proposal was to talk about the
places you plan on rewriting in Lisp before you have a patch, because
I'd prefer to avoid the situation where you invest a significant
effort, only to see it voted down.

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

That'd be a good thing in general, but creating a new Lisp file for 2
functions is probably overkill.  And it still has at least some of the
disadvantages I mentioned: the code which was there for eons gets
moved around.