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.tangents Subject: Re: Shrinking the C core Date: Tue, 12 Sep 2023 14:55:55 +0300 Message-ID: <83jzsvppv8.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37445"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-tangents@gnu.org To: Arthur Miller Original-X-From: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Tue Sep 12 13:56:51 2023 Return-path: Envelope-to: get-emacs-tangents@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 1qg20e-0009Hr-Gd for get-emacs-tangents@m.gmane-mx.org; Tue, 12 Sep 2023 13:56:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qg207-0002Oq-Fa; Tue, 12 Sep 2023 07:56:16 -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 1qg204-0002Nl-LW for emacs-tangents@gnu.org; Tue, 12 Sep 2023 07:56:13 -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 1qg204-0005uE-5h; Tue, 12 Sep 2023 07:56:12 -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=ZssUMRwFyINEeb7y/L0GJy99TdrG0yAY34W19fvn2aE=; b=fhGNAhnYe3Yw CuUTL51GjjOTZ3YB7Zp2U7bakci2Olx7Zmyx0s/gXrLWRPiK6lOjh3zVK/A2aYPELpnKAjnQov67e LvhuF4ck8FH7q8QRdiGdoRc95IR8M9GE+0cGi9QQ12QkUPPTxVxLTWVVLuhxfMosKRyCy1W08fryH y+Pi6sW0jUOjwiDVQFF3OXXfU6pxkokXdyrmsnwJ7ySZHs6msOARjk0Jx2NtnfcQpg6sEQZ+AkZE+ Pvt4Ubspp/QzAWYQRsOO7fs5Hfhg/K65zaBYJtL+0PtogDWC56tG5wgtelYIoHoHBNJB8TYJX6bRE xcDM/NuirlwTMwiPaEVuqg==; In-Reply-To: (message from Arthur Miller on Tue, 12 Sep 2023 05:46:37 +0200) X-BeenThere: emacs-tangents@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Original-Sender: emacs-tangents-bounces+get-emacs-tangents=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.tangents:1064 Archived-At: [Redirected to emacs-tangents.] > From: Arthur Miller > CC: emacs-devel@gnu.org > Date: Tue, 12 Sep 2023 05:46:37 +0200 > > Mnjah; you know as well as I, and I have written it in the very first > mail why I want Emacs in Lisp. There are already other applications and > editors inpsired by Emacs, that is not the question. Problem with them > is they can't run Emacs applications and they don't have Emacs manual > and the well written documentation. I think it would be waste of the > effort of many people to throw it away. You may disagree and that is OK. It will not be a waste of effort if the "neo-Emacs" will take into consideration the main lessons we learned during those 40 years, and will have a different architectural design to avoid the pitfalls and allow extensions we cannot currently support. Reimplementing the same design in a different language, be it SBCL, Python, Go, Rust, or whatever -- that _is_ a waste of effort, because you will have the same Emacs with the same basic restrictions and limitations, which are really not expected from a modern GUI program. We tolerate them in Emacs because in return we get so much and because the performance is still reasonable as long as we can live with the limitations, but starting a radically new implementation from the same point with the same basic design means that we will have to tolerate those same limitations for decades in the future, and that's simply silly. The net result will be a huge effort, lots of work to stabilize the result to be anywhere close to what we have now, and all that for what? Which is why anyone who understands the internals well enough to do the job will never do it. Yes, this can be done in principle. But it shouldn't. P.S. And don't be afraid of losing some of the applications and the documentation -- these should be the least of your worries. Sticking to the same design for these reasons is ... I don't even have civilized words to describe this kind of thinking.