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

[Stefan Kangas]

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