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: Thu, 14 Jan 2021 22:10:32 +0200 Message-ID: <83lfcvb7pj.fsf@gnu.org> References: <83zh1cbpua.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22175"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 14 21:11:35 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 1l08xz-0005fR-3J for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jan 2021 21:11:35 +0100 Original-Received: from localhost ([::1]:34992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l08xy-00077x-4v for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jan 2021 15:11:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53868) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l08x7-0006bQ-1h for emacs-devel@gnu.org; Thu, 14 Jan 2021 15:10:41 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58364) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l08x6-00020m-FO; Thu, 14 Jan 2021 15:10:40 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4726 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l08x3-0002rz-M0; Thu, 14 Jan 2021 15:10:38 -0500 In-Reply-To: (message from Stefan Kangas on Thu, 14 Jan 2021 13:24:10 -0600) 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:263053 Archived-At: > From: Stefan Kangas > Date: Thu, 14 Jan 2021 13:24:10 -0600 > Cc: emacs-devel@gnu.org > > AFAIK, the main reason to have things in C is if there is a performance > benefit to doing so. That's not the only reason, but I think for code that exists for a long time the reasons are no longer relevant. The code was written like that back then, and we should only change it if we have a good reason. I don't see such a good reason in this case, and without that such changes are a needless churn with no benefits. > The reason for this change (and the previous commit) is simple: I > noticed that there existed a handful of functions in keymap.c that > does not see any such performance benefit. If this means you'd want to move to Lisp every piece of C that doesn't need to be fast, then I don't agree with that, sorry. Surely, we have better things to do with our time and resources than move code from one language and file to another without changing anything in functionality. Our main task here is to develop and extend Emacs by improving existing features and adding new ones; let's invest our efforts mainly in those directions. Cleanup is only secondary, and these particular changes cannot even be qualified as cleanup, as the original code was as clean as it's now after being rewritten almost verbatim in Lisp. > There is IMO no reason not to reduce the number of C primitives where > possible. Lisp is a superior language to C, for all the usual reasons. > It is also better supported in Emacs itself in terms of debugging, > advising, etc. The reason not to do so is what I wrote in my previous message: it gets in the way of finding the code which does something when you need it, whether to recall how it works or consider some changes there. Whether we move to Lisp, change the names, or do something else which doesn't affect how the code works, we make it harder to find the code without grepping or using M-., and that slows me down, sometimes considerably so. (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.) > As for future plans: > > - I have a patch for `describe-buffer-bindings' that I intend to finish > up soon (after fixing an unrelated performance regression bug). This > has more obvious benefits than the trivial case discussed here. 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. > - There are a handful other functions in keymap.c that could usefully be > moved to Lisp. If it's for the same reasons as you described above, then let's please not do that. I'm not interested in moving as much of keymap.c to Lisp as possible if the motivation is that just rewriting in Lisp makes it somehow better; I disagree with that motivation. > > And why don't we discuss such changes before making them? > > If you prefer, I'm of course happy to send any patch for review before I > make any more changes like this. I meant discuss plans such as this one, not necessarily each and every changeset. If the general idea behind some series of changes is agreed upon, I don't think posting each changeset will be necessary. > > If nothing else, it makes it harder for people who, like me, are > > familiar with the original code, to find stuff, because suddenly it > > isn't where it used to be. > > The functions we are discussing here are rarely used, AFAICT, so I'm not > sure I understand this point. Well, frankly I don't understand it even > if they were used a lot. > > (FWIW, I use `xref-find-definitions' or `describe-function' to avoid > having to memorize the locations of functions.) 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. That gets in the way when I need to find some code quickly without necessarily knowing the exact names of functions and variables -- and I need that a lot, whether to answer a question, consider some possible reasons for a bug report, etc. Besides, when you move stuff to Lisp, it loses one of the two identifiers by which it is known: only the Lisp identifier is left, the C identifier is removed. So even M-. will only help if you use the Lisp identifier, which is another thing one has to remember or guess when the old code is not there to be found. And having code I'm familiar with disappear from where I used to find it is a disorienting experience: I frequently begin to question my memory regarding the name of the function or variable, or even that we indeed have the code that I'm looking for, and it is generally an annoyance and a slowdown. Maybe you are not yet familiar with the code enough to be affected by these changes, but I am. Please respect my workflows. I hope you now understand better why these changes are an annoyance. If they are done to gain some new features or extend existing ones, then these annoyances can be justified. But we gained nothing like that in this case. You are not the only one who works with this code base. > > It's a needless churn, and I ask myself what do we gain in > > return? > > Emacs will be around in 40-50 years still, and we should maintain it > with that in mind. Every time we make code more readable and > maintainable, we make our life easier in the long run. I don't really see how moving stuff to Lisp in these cases makes the code more readable or maintainable. You basically wrote the same code in Lisp as it was in 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. TIA