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, 21 Jan 2021 21:59:04 +0200 Message-ID: <83zh125aev.fsf@gnu.org> References: <83zh1cbpua.fsf@gnu.org> <83lfcvb7pj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39319"; 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 21 21:01:11 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 1l2g8k-000A7C-UU for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 21:01:10 +0100 Original-Received: from localhost ([::1]:38406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2g8j-0005WZ-Vv for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 15:01:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38710) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2g6p-0004C1-7D for emacs-devel@gnu.org; Thu, 21 Jan 2021 14:59:12 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49000) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2g6o-0002rW-Fe; Thu, 21 Jan 2021 14:59:10 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4145 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l2g6n-0003Xl-4c; Thu, 21 Jan 2021 14:59:09 -0500 In-Reply-To: (message from Stefan Kangas on Thu, 21 Jan 2021 10:03:28 -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:263251 Archived-At: > From: Stefan Kangas > Date: Thu, 21 Jan 2021 10:03:28 -0600 > Cc: emacs-devel@gnu.org > > 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. > [...] > >> 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. These high-level arguments completely miss the point, because the disagreement is not on that level. This isn't about which language is better for implementing Emacs features, not at all. But agreement about that doesn't mean we should rewrite in Lisp every piece of C code we have. I tried to explain what are the practical aspects that I think need to be considered in cases such as the one which started this thread. Your response completely ignores most of those points. > > 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. It's okay to send a ready patch, but my proposal was to talk about the places you plan on rewriting in Lisp before you have a patch, because I'd prefer to avoid the situation where you invest a significant effort, only to see it voted down. > > 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.) That'd be a good thing in general, but creating a new Lisp file for 2 functions is probably overkill. And it still has at least some of the disadvantages I mentioned: the code which was there for eons gets moved around.