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: Emacs design and architecture (was: Shrinking the C core) Date: Sun, 17 Sep 2023 09:31:37 +0300 Message-ID: <83cyyhgvjq.fsf@gnu.org> References: <87ledwx7sh.fsf@yahoo.com> <877cpfybhf.fsf@yahoo.com> <873503y66i.fsf@yahoo.com> <87fs3ur9u8.fsf@dataswamp.org> <875y4moiiq.fsf@dataswamp.org> <83r0n4rj78.fsf@gnu.org> <83cyynpmvd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28694"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Sep 17 08:32:48 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 1qhlKp-0007EG-6o for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Sep 2023 08:32:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qhlK0-0007p3-QY; Sun, 17 Sep 2023 02:31:56 -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 1qhlJz-0007l9-TN for emacs-devel@gnu.org; Sun, 17 Sep 2023 02:31:56 -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 1qhlJz-0005KD-Ko; Sun, 17 Sep 2023 02:31:55 -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=/j/tsb0ESixMetxCKM+i5tQ/MMQWMB9AuHUaXGmbFf8=; b=fe1D+zvaA3M5 5a62Y6PwpbbmRYML3SO+jr8vSjEKLcBocd/KELxIFdxfLOOHCOqdw13dL2zVOkTjt0ZJ0cqNK3LzY /rZyVwW8ubt+T5LceAGnsYQvKemiwAdgg19nW+dbJ9khlAknrHtSZCLpq5tzrejAMZcOiHKP4mpep NIy0Pijf+hRHz1zpJrVDmlbBZAqkVtw+lZNMb3Gsg2f/I9gahWymgLOL+DcY2QS1I4P2IHpfEiSQq bk16uHilpHgMdpePpZoSeNOqeD5ANAwTyItzOH6CV2AI2ykaT+NQDm51YE/3Z4lXhHCag+QyOFvMu NwWb0gjiuwlBqiQx+KAs3g==; In-Reply-To: (message from Richard Stallman on Sat, 16 Sep 2023 20:45:00 -0400) 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:310653 Archived-At: > From: Richard Stallman > Cc: owinebar@gmail.com, emacs-devel@gnu.org > Date: Sat, 16 Sep 2023 20:45:00 -0400 > > > . "buffer with gap" for storing buffer text > > . "mark and sweep" GC > > . basic single-threaded MVC architecture > > . display engine design around the rectangular canvas model and > > on-the-fly layout decisions > > These are internal design decisions. > The last one does relate to some user-level features > such as data in the buffer. The first three don't. > > So I don't see these as being related to simplicity > that benefits the users. That is true, by and large, but the simplicity that benefits users is not the only issue at stake. There's also the issue of being capable of performing complex computations efficiently, i.e. quickly and without locking up Emacs; multi-threading and a more modern GC could give us at least some of that. Being able to use multiple execution units in parallel is also the main (perhaps the only) path towards letting Emacs make good use of modern system architectures. > A more complex and powerful data structure in the buffer is something > I would like to see. I would like it to enable TeX-style formatting > of text for display. In off-line discussions with Stefan Monnier, we both arrived at the conclusion that some basic limitations of the current display engine cannot be lifted without redesigning how buffer text is stored and accessed. So yes, buffer's data structures are an important factor in what features we could introduce in the future, in particular related to sophisticated and efficient redisplay. > However, finding a good design for this will be a hard job, I think. > We would want it to facilitate redisplay and also be easy for editing. > It needs to support editing primitives of the traditional Emacs kind, > which treat text as a sequence somehow (even if not the same as now), > and editing primitives that operate on the structure and make them > convenient. Right. > All four of those directions are basically independent. > Any one could be done with or without the others. They are not completely independent, no. They _could_ be independent if the design of each direction took into consideration the possible designs of the other directions up front, so as not to preclude developments of those other directions or make them too hard. And doing some changes in only one direction could mean unnecessary work. For example, any significant changes in the display engine without simultaneous changes in buffer text access would mean either writing code that will be tossed in the future, or coming up with some abstraction that could be easily changed when buffer text access changes; both mean non-trivial extra efforts. Likewise, redesigning buffer text storage and access must have the display engine needs effect the main design decisions, even though redisplay is not being reimplemented at the same time.