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: Shrinking the C core Date: Thu, 10 Aug 2023 09:48:36 +0300 Message-ID: <83msyzjsu3.fsf@gnu.org> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <87il9owg0f.fsf@yahoo.com> <87ttt7odzh.fsf@arch.mail-host-address-is-not-set> <87leej7ima.fsf@gentoo.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17457"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ericfrederickson68@gmail.com, esr@thyrsus.com, emacs-devel@gnu.org To: Sam James Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 10 08:49:01 2023 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 1qTzTg-0004H5-MR for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Aug 2023 08:49:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTzSu-0000bY-If; Thu, 10 Aug 2023 02:48:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTzSs-0000bB-Lz for emacs-devel@gnu.org; Thu, 10 Aug 2023 02:48:10 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTzSs-00010v-2C; Thu, 10 Aug 2023 02:48:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Cffcos3El+iGMww6NrwrXpokYJe7MYMQOVZwqnPStRs=; b=Q7oo9QVJ8x44 rHHIT3ndbm8FIzscL8lWRUiMqzSsPhspAdM+/WNQN4babBRP45hvK7acRCpO45iffwvLMkKFm9CcP oYBewddhySfk7lFzP0LcquOtL5m4PhPijzNPj63mgHxrvzwYzhkGZ5WGDV3yFhVElRgF3syCEeLZI Jb3WSoy6rJ3VnF+MV+UYSSh4UoRSX/2BbrUYJ2NZaPit4fUCPv50dVS8pq0mL7L8gGr7tp2ENHRHI 9kDGD4xiPdyR0W//jwMYfIq5B96roDUXeXs+yIsFX0cm1RLyA/c242kmK/yfd9zUSGmYStW7sUdx6 J4/wCjHmTaht0OQMiVLGbA==; In-Reply-To: <87leej7ima.fsf@gentoo.org> (message from Sam James on Thu, 10 Aug 2023 03:07:58 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308510 Archived-At: > From: Sam James > Cc: esr@thyrsus.com, emacs-devel@gnu.org > Date: Thu, 10 Aug 2023 03:07:58 +0100 > > While not being up front about the changes is of debatable wisdom, I > didn't find it particularly alarming given I at least have always > understood the aim to be to have the C core as small as possible anyway. There are no such goals, no, not where I'm standing. We do prefer to implement new features and extensions in Lisp if they can reasonably be implemented in Lisp, but rewriting existing C code in Lisp is not a goal in and off itself. > Laying the groundwork for something that may or may not come off with > independent changes one believes are worthwhile isn't underhanded if > it's just a pipedream in the back of your head but you think the changes > are good in isolation. Assuming I understand what you mean by that: we've been burnt in the past by people who started working on some grand changes, made package-wide preparatory modifications, and then left to greener pasture without arriving at any point where those changes have any usefulness. That's net loss: the code is less clear, gets in the way of the muscle memory of veteran Emacs hackers (who used to know by heart where some particular piece of code lives and how it works), and brings exactly zero advantages to justify these downsides. So now I'd prefer to start such changes only if there's a more-or-less clear and agreed-upon plan for the new features, and generally do that on a feature branch, so that we could avoid changes on master before they are really useful and agreed-upon.