From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture (was: Shrinking the C core) Date: Wed, 13 Sep 2023 23:19:03 +0200 Message-ID: References: <873503y66i.fsf@yahoo.com> <87fs3ur9u8.fsf@dataswamp.org> <875y4moiiq.fsf@dataswamp.org> <83r0n4rj78.fsf@gnu.org> <83cyynpmvd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34496"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: rms@gnu.org, Lynn Winebarger , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 13 23:20:13 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 1qgXHQ-0008hi-LP for ged-emacs-devel@m.gmane-mx.org; Wed, 13 Sep 2023 23:20:12 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qgXGX-0004Li-KJ; Wed, 13 Sep 2023 17:19:18 -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 1qgXGV-0004LL-77 for emacs-devel@gnu.org; Wed, 13 Sep 2023 17:19:15 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qgXGO-0001XB-70; Wed, 13 Sep 2023 17:19:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1694639943; x=1695244743; i=dimech@gmx.com; bh=PtO2DqqAkGgBVOk6E6Ky6ZCYDsRg9EeN70YDoma7L3w=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=XyU3znH8VIZg3W6BAasyMTMJN9Qrt65UuDoOQ+RA0eibiQuWSbpKmzP0FIWjF0wocxku+NC6D1h 513qhTyYd/23swvLF2WRvi/G8qn0acjGzuFCO3zwkonDGGSPUXmiT9PInNEIcXQdY7ZpdIYnNN9N0 H90cpZDAt//CNLHj1eF006TMViRzuyIkyDCdFOWUt1cCFzpZUoSTv7DDGZT+DV3KZqCGqwwqxt/vp 7c1GIaSdV5KY3v5MXEdWs65pkmmGdjTUyhevKcXhdOJdErWi0p4eLOv5CA+CEwIDdrR57VTkW1EYg xTCHMqCwpcamZ8drZBgsTExsZsJamJd0uAew== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [141.8.81.247] ([141.8.81.247]) by web-mail.gmx.net (3c-app-mailcom-bs10.server.lan [172.19.170.178]) (via HTTP); Wed, 13 Sep 2023 23:19:03 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:FBcmGH3oiCdKPAltXoLwnTJBI3/NoEnJMVJWHk5eeU7WJcLxxHJeaG3fj1IUKdWueuhTw RQtRH0QZCEltSuH92JSUUL59GSRiH1XONQuQ/+FHklRV8U5QkVEN67k4W05dHw+wNd9CkAiSiYJ3 VZjMqNrWwiAdlvbZaaMSTEuPKc8V50aZoybHZtUxW5Uj06qkWZP7wW2RLTiT+wfb/OfGc5orCTow QYe63ugOoetNNLXzpU1xk16E5qVNKMXHTEAmXI5qeSL78Ws0ltNS2ULGTEkHCBQgW+qkD/jOiOqS Ak= UI-OutboundReport: notjunk:1;M01:P0:ICi/AD5a8V4=;b2RkcuF6pAecC5cesVvEJk6xaca O9lMM/g+MqXpUqHm+cSQIZuQoiNdUt2dNdDGu7RxLaLIjgWdXEHB6OvXHgJW2mToL5dx2jpKb sAXDA04KlBVQ8M2rf4U0sL+nCGQ+TRi6snuj+kLNafAqw1mDkvpSbSVQ3a88DuP3BFavWQsX/ +2MhtAY8kdTqH0bNZf3mXJqyVcR4ywV5uJYx9zJbeWI8KrJzOcE8zhJXw84z4B1gXog4yq40R CUQHWJaKGFlQqRMymLPCYFzTovQXQmZQVWVD0ay+eOElZT8QPzLy9CElJVs2VCWgRwPOhpxQ5 pS3RIJquNQDbLCbVshwJECVKgdVuJ38HYa6c6H2Qr4B0vGgo/NtVWQ6fK5yhgOP1GY57dJApu dRkIfSdFxd2I9REIX1Q7SwxYvHLRo55W8hDid07itesraljpDJOmT/PeFkX9QIfrv8LmlPw2B yV2J3eGx1I+ibPxg/sC97d5suouMYEeFVj1Kb02W9Ymzy7IsxG+zhkqFJ1JnRSD53B5LEAHfj TVlhTbbF2Nx/fPKatoItO+MhCumKhBenpmv6FXUB9dxm98x1niWoTjCWgRXcKfBPhuHRgbpxi wdbk130PjDBrDkNFhaSlGdkbSjp1XUyV8kOw00hcGEEl7TaQ8hJ7B9U57Vi9l6/Q3s0hfE8/d BD//Ut4gLPqBRxnrY2bmzupSVtIbGa1DhojFNwCLUOnhmuhpSIwmMR/yGQ7ChI8B0s5xzwJzI 2LS56NlR07nu5zaAxGHs1X+/5YyxRwqz4Bj5vJiwidpBOOBH18qkfLNzW6U0bkh7/OlthFxM Received-SPF: pass client-ip=212.227.15.18; envelope-from=dimech@gmx.com; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:310556 Archived-At: > Sent: Thursday, September 14, 2023 at 8:52 AM > From: "Lynn Winebarger" > To: "Eli Zaretskii" > Cc: rms@gnu=2Eorg, emacs-devel@gnu=2Eorg > Subject: Re: Emacs design and architecture (was: Shrinking the C core) > > On Tue, Sep 12, 2023 at 9:01=E2=80=AFAM Eli Zaretskii w= rote: > > > From: Lynn Winebarger > > > Date: Tue, 12 Sep 2023 07:31:35 -0400 > > > Cc: Richard Stallman , incal@dataswamp=2Eorg, emacs-d= evel > > > > > > If Emacs will ever be "rewritten", it will not be Emacs, but a > > > text-processing system with a very different architecture and desig= n, > > > which will take from the Emacs experience the lessons we learned an= d > > > implement them differently, to produce a system whose starting poin= t > > > is closer to the needs of today's users and whose main technologies > > > are more modern from the get-go=2E One thing that needs rewriting is texinfo to use the latest functionalitie= s=20 that are provided by the LaTeX3 Project (https://www=2Elatex-project=2Eorg= /latex3/) Today we continue to be restricted by what the TeX Core Engine can do=2E We are continuing to work with the pre-1983 version before Leslie Lamport= =20 developed LaTeX, a higher-level markup language built on top of TeX=2E=20 > > > It sounds like you have some specific ideas=2E I wouldn't mind hear= ing them at more length=2E > > > > They are all well known=2E And they aren't ideas, just main design > > features of Emacs which we found restrictive in some aspects: >=20 > I think I was more interested in why you said it would be a > "text-processing system" rather than an editor or even IDE, what you > perceive as the unmet needs of today's users, and what modern > technologies you think are applicable to the problem=2E I'm not an > expert in the display or text-encoding aspects of what Emacs does, so > I really don't know what you have in mind=2E I do have some ideas in > terms of extension language implementation=2E There are definitely some > techniques used in implementing V8 that could be brought over=2E >=20 > > =2E "buffer with gap" for storing buffer text > > =2E "mark and sweep" GC > > =2E basic single-threaded MVC architecture >=20 > These three I have some ideas on, which I've outlined previously, > using git and other distributed VC techniques as inspiration=2E > However, those are longer term goals=2E For my first effort, I'm > focusing on some low hanging fruit for creating tree-sitter parser > tables and lexers in elisp and being able to create them dynamically, > with some supporting technology that can also be applied to more > generic dumping and garbage collection=2E >=20 > > =2E display engine design around the rectangular canvas model and > I don't know what the alternative is, exactly=2E VS Code and other IDEs > I've used have more varied decorative elements and containers, but > text is still pretty much presented in rectangular containers with > sides parallel to the GUI window (frame in Emacs terms)=2E >=20 > > on-the-fly layout decisions > > > > > My understanding is the design is deliberately kept simple (or "simp= le") to make it accessible to > > > more programmers=2E > > > > Richard will tell, but I don't think this goal was ever of high > > priority, back when Emacs was still being designed=2E > > > > > Instead of discussing porting emacs to CL, why don't people work on= porting the compiler > > > techniques used in CL to emacs? > > > > Well, native-compilation is one step in that direction=2E We've been > > discussing something like that for many years, and we even tried a > > couple of approaches (which didn't work)=2E Native compilation is the > > first successful experiment in that direction=2E Working on making th= e > > native code more efficient is definitely encouraged=2E >=20 > It's on my agenda=2E Not native code, per se, though=2E I think there > are some changes to the VM design (that the native code has to be > consistent with) that are required=2E The strict stack discipline is > inherently inefficient, and since not every function parameter is > dynamically scoped, there are plenty of opportunities to optimize away > unnecessary function call overhead=2E That and more efficient GC design > go hand in hand=2E >=20 > Lynn >=20 >