From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Lift {global,local}-key-binding to Lisp Date: Fri, 15 Jan 2021 09:42:40 +0200 Message-ID: <838s8ubq8f.fsf@gnu.org> References: <83zh1cbpua.fsf@gnu.org> <83lfcvb7pj.fsf@gnu.org> <87o8hqhm23.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39389"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 15 08:43:17 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l0JlM-000A4K-Qa for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Jan 2021 08:43:16 +0100 Original-Received: from localhost ([::1]:37190 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0JlL-0007ui-TA for ged-emacs-devel@m.gmane-mx.org; Fri, 15 Jan 2021 02:43:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0Jkr-0007W6-Px for emacs-devel@gnu.org; Fri, 15 Jan 2021 02:42:45 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40662) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0Jkq-0000D0-Hk; Fri, 15 Jan 2021 02:42:44 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3487 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l0Jkp-0000j8-VK; Fri, 15 Jan 2021 02:42:44 -0500 In-Reply-To: <87o8hqhm23.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Fri, 15 Jan 2021 05:16:20 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263069 Archived-At: > From: Óscar Fuentes > 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.