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

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 15 Jan 2021 05:16:20 +0100
> 
> Along the years you repeatedly and justly expressed concerns about the
> future maintenance of the C code base due to lack of hackers with the
> required skills. Anything that reduces the number of lines of C will
> mitigate that concern. Plus, moving things to Elisp will remove the
> requirement of knowing C (and all its Emacs-specifc idioms) for hacking
> on the corresponding features.

My concerns you mention above were about new features, so their
applicability to rewriting existing code is limited at best.  And I'm
not against moving stuff to Lisp as part of implementing new features
or improving existing ones.

Knowledge of C will remain a basic requirement for Emacs maintenance
for the observable future.  Moving small amounts of code to Lisp will
not change that in any way.

The code that was moved, and the code that is proposed to be moved,
didn't see any significant maintenance: the last change in these
*-local-key-binding functions was 10 years ago, the one before that in
2004 (doc-string fixes), the one before that in Feb 1993.  Thus,
easier maintenance is not an important factor in this particular case.

Moving such obscure C code which saw no significant changes in the
past 18 years to Lisp, with no other motivation and without even
restructuring the code, has no advantages, but does have
disadvantages.  One disadvantage is the disorientation effect I
mentioned before.  Another is destabilizing Emacs: Lisp code becomes
available only after 'loadup', so if anything we do at build time
before that needs this code, it will become broken, and the test suite
will not be able to detect that.  More generally, any change that
doesn't provide a clear advantage is by definition bad because it
risks introducing bugs where previously there were none.  Why risk
that without a good reason?

> I look forward to the time when, thanks to native-comp and FFI,
> everything is implemented on Elisp except for a tiny C core.

How do you know that what we have now in C isn't already that tiny
core?  What are the criteria for that decision?

Anyway, Emacs is not an academic research project, it's a living
project which is used by many people for doing their day-to-day tasks.
Apart of developing it, we also have an obligation not to destabilize
it without a reason, not even the development version on the master
branch.  The balance between cleaning up old code and not introducing
unnecessary destabilizing changes is a fine and tricky one; general
philosophical considerations won't cut it -- we need to carefully
consider each and every specific case.  Being in charge of keeping
that balance, I'm asking you and others to trust me here.