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, 21 Jan 2021 10:03:28 -0600 Message-ID: References: <83zh1cbpua.fsf@gnu.org> <83lfcvb7pj.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="28620"; 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 21 17:04:52 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 1l2cS3-0007Lo-On for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 17:04:51 +0100 Original-Received: from localhost ([::1]:51878 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l2cS2-0002j3-QZ for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Jan 2021 11:04:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35578) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l2cQn-0001zF-L4 for emacs-devel@gnu.org; Thu, 21 Jan 2021 11:03:33 -0500 Original-Received: from mail-pf1-f179.google.com ([209.85.210.179]:37427) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l2cQl-00064d-PM; Thu, 21 Jan 2021 11:03:33 -0500 Original-Received: by mail-pf1-f179.google.com with SMTP id 11so1759810pfu.4; Thu, 21 Jan 2021 08:03:30 -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=RwL8jaXeUt++2xISaJKEqS8xAjx4Ur4KRvDGFt11VEQ=; b=LApNBC9V8pLJfmoijsPx3DPO12AUM69e+oAbtnaOsnrYtrISnjaAzsa5PsM3Zs2vBv hg/6dZ3yfra47G3P5AHdCVy6lNSx5SGpv5EnGGm/7uMOwWi1fcH8eDvQXAg4f+Jocod7 9ZeXURvnignAk1Zw+zWX6p1/r3dtYdApF3YsJnUViIuH9ZwXWR6f+/RWDEhIYv2QcIUD LneAv2Srj2BXrlxwxj9r8Opi8bFtO9g+li+hqGUVUijzHu4QLFFuKKWGHrvdMIu/1jCq 2UCuk5TPj0pdbDR82+j0/kkxpIUEcTVMpR/kqlhUZiOjffo/ev1j1Mf5KvMgHUMdmevv mB9w== X-Gm-Message-State: AOAM533tzjt4eovynOw3XHNwWJQcjICd6ytK+jcIzSX2d2pxrMYg7JKC 7BKbqOVskAmxqJfQgiOb1q0tYazHLzPRaHf4DyDlzfry X-Google-Smtp-Source: ABdhPJysQcKlIfemPt6ElYHA049nSnOAxMgepZcU/MjTd+ZSs8cgNXYql10JkJvZdoFOSzTJ/7IY0SMnDp6xmX3ItPg= X-Received: by 2002:a63:e108:: with SMTP id z8mr14910147pgh.363.1611245009456; Thu, 21 Jan 2021 08:03:29 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Jan 2021 10:03:28 -0600 In-Reply-To: <83lfcvb7pj.fsf@gnu.org> Received-SPF: pass client-ip=209.85.210.179; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f179.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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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:263240 Archived-At: (Sorry for the late reply, I have been swamped with work.) Eli Zaretskii writes: > If this means you'd want to move to Lisp every piece of C that doesn't > need to be fast, No, I have not suggested any such thing. I said that there were a few functions in keymap.c that I think we could usefully move to Lisp. > (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.) 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. > 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. > 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.) >> 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.