From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture (was: Shrinking the C core) Date: Tue, 19 Sep 2023 06:22:36 -0400 Message-ID: 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> <83cyyhgvjq.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9465"; mail-complaints-to="usenet@ciao.gmane.io" Cc: owinebar@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 12:22:59 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 1qiXsg-0002DR-TK for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 12:22:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiXsN-0005ON-0A; Tue, 19 Sep 2023 06:22:39 -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 1qiXsL-0005OC-LH for emacs-devel@gnu.org; Tue, 19 Sep 2023 06:22:37 -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 1qiXsL-0008Ie-8d; Tue, 19 Sep 2023 06:22:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=lMFhDNqmdgYD/uadqaLyZUuzafGSGz0vYCRv1zo+P1k=; b=Ov0v3aNjlNR5 3/S54vaIJY6BeyQHSMNEIloc4hh4VMeqYpeJbvLVWfPKAF1IUbXuyY5cqrOYrKqbG/gkzoSyg7TFf 5Dtjew8Ly8ABq0omT8cjUDnoe7ZYLbk7gSQiObTfXgBivOCFT3bl1dgK+t2NiympKOpakWNpTgNWZ Z28cKc0P+yPM3YFvtMc+xRzEilMTs3dwjOdrDTjYYXprON/4mp+hblCgb4DofmOnTZufa7Dzbj35p 77FbqKWpOGed3nr72cvfC9V9mDq3cuiJaU21bCmNM6ixBkPGGLtDXQg8I4wZYtTuHpgTmth3Jtsza VcWSdsXQo/ZTfbRGl/FS+g==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1qiXsK-0004vx-VS; Tue, 19 Sep 2023 06:22:37 -0400 In-Reply-To: <83cyyhgvjq.fsf@gnu.org> (message from Eli Zaretskii on Sun, 17 Sep 2023 09:31:37 +0300) 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:310744 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > 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. I agree, these kinds of changes > > . "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 could possibly be improvements. I was arguing only against one putative benefit, "simplicity". > 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. I agree they would require something more powerful than text properties and overlays as they are now. Text properties were designed to work consistently with copying text between buffers and strings, and that imposed a limit. What made this conceptually simple was the idea that each character individually has its own properties. If we add a more powerful method of attaching non-text data to buffers, the design phase should include specifying precisely how they would behave when copying text between buffers and strings. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)