From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Lift {global,local}-key-binding to Lisp Date: Thu, 14 Jan 2021 13:24:10 -0600 Message-ID: References: <83zh1cbpua.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 14 20:28:20 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 1l08I8-000720-EX for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jan 2021 20:28:20 +0100 Original-Received: from localhost ([::1]:35252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l08I7-0002sL-Gi for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jan 2021 14:28:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41006) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l08EC-0007i1-Gg for emacs-devel@gnu.org; Thu, 14 Jan 2021 14:24:16 -0500 Original-Received: from mail-pg1-f175.google.com ([209.85.215.175]:39998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l08EA-0003SA-K8; Thu, 14 Jan 2021 14:24:16 -0500 Original-Received: by mail-pg1-f175.google.com with SMTP id 15so4448795pgx.7; Thu, 14 Jan 2021 11:24:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=PyTSqX+rcz9e9+65ZwQiQX8FJevQ4wM7ebC/3+s6F8k=; b=kOjyqJgZjNaegNhtq3ELQKWaKHvj7xpBSZaVGuGSOyMAGpNSo/G+R2L/iO5LlXylXl NqAxtZXsEZ/PYZV5gYXLUtKWlSqBKzQtPpqe/KMq7+rUG/dbeu+pyEv1r6qojKSs7IQ6 +pHvTIlXplIM+8izQCTkKYInBj5gHjO6m+QInkpCMUZ2RuPIgnknvKf4joUAPNTuJK5S LIhLODWG9vxraBdogOc3yNl0JxYO3VnkUzNmoOjmX1buS8l3T5dzA8io7AoCgB98cXEd iaoCGtZIR0ERIH6GCVGR9XLS91LAlrQdqRFE2hn/gkMcwSVhp3hmTklCAJLhb6UkqHvw JovA== X-Gm-Message-State: AOAM531b+n8ptJBz4Q1YfttucG9YIltJvY0olCEvNwN8w61w9B2h01+k Kh+Tr+2xh1y4045YeiI25I29pxStGr11lAa45giNwI3o X-Google-Smtp-Source: ABdhPJwkb/UEcYARpePxFblD9yRPdPNQYk5UMbK7Ca87clo7LANY6cm/Rx4Bf93llcGVKBBPp4OxKAHfJKuf029exDY= X-Received: by 2002:aa7:8550:0:b029:19e:46e7:913b with SMTP id y16-20020aa785500000b029019e46e7913bmr8690969pfn.58.1610652252113; Thu, 14 Jan 2021 11:24:12 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 14 Jan 2021 13:24:10 -0600 In-Reply-To: <83zh1cbpua.fsf@gnu.org> Received-SPF: pass client-ip=209.85.215.175; envelope-from=stefankangas@gmail.com; helo=mail-pg1-f175.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:263051 Archived-At: Eli Zaretskii writes: > Stefan, why are we moving these and other functions to Lisp? Are > there any advantages to moving them? AFAIK, the main reason to have things in C is if there is a performance benefit to doing so. 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. 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. 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. - There are a handful other functions in keymap.c that could usefully be moved to Lisp. > 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 had already intended to do so for the somewhat more complex case of `describe-buffer-bindings', but did not realize it would be necessary for these trivial ones. > In general, unless we get some significant gains, I'd prefer not to > move around code just to move it. It is hard to disagree with this point, in general. But that was not the reason for moving it, see above. > 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.) > 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. Yes, at the minor price of actually making the change. 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.