unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Óscar Fuentes" <ofv@wanadoo.es>
Cc: emacs-devel@gnu.org
Subject: Re: Lift {global,local}-key-binding to Lisp
Date: Fri, 15 Jan 2021 09:42:40 +0200	[thread overview]
Message-ID: <838s8ubq8f.fsf@gnu.org> (raw)
In-Reply-To: <87o8hqhm23.fsf@telefonica.net> (message from Óscar Fuentes on Fri, 15 Jan 2021 05:16:20 +0100)

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



  reply	other threads:[~2021-01-15  7:42 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
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 [this message]
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=838s8ubq8f.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=ofv@wanadoo.es \
    /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).