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: Tue, 19 Sep 2023 17:31:53 +0300 Message-ID: <83cyyecjza.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> <83cyyhgvjq.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15506"; 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 Tue Sep 19 16:33:22 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 1qibmy-0003ld-KD for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 16:33:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qibm2-00039z-Ed; Tue, 19 Sep 2023 10:32:22 -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 1qibly-0002xt-OX for emacs-devel@gnu.org; Tue, 19 Sep 2023 10:32:19 -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 1qiblx-0005dg-Tm; Tue, 19 Sep 2023 10:32:17 -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=851cOVEwRVla86cQXM/oKpNXU6/qDzdKOTlmnNWOciY=; b=TzoK3i9ZPG7D JwkVBL04NNJs2fvcAINkMQRSnATJuCXW2Hlk8QB9YIDSIm2tpaaQAauW4gU/XpnnprprMMqrn0z3x Gm5tdBuBO5ubGQ9M39AHZUJbHzoV5JeVwV8G5hD6CyTLep9xu/qBooeg6VDDKJM7jVwRS2hnlNixd CIGPNot6ndV6hr0T0OXtHXtehKQRQYgCE0gU54Yvz7PlshCAbguoxqVpedvQL7+shY5QhDEPKVFsB w/et8XH6qZks7CviR7EmOuyLUxmXTVlXkL1cEeMHQeF3Nhrs26r/wU9v4Vy5iUQrGHGFArIkYWhVB cDCdGEyiNIOrUEIiwhSyEg==; In-Reply-To: (message from Richard Stallman on Tue, 19 Sep 2023 06:22:36 -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:310772 Archived-At: > From: Richard Stallman > Cc: owinebar@gmail.com, emacs-devel@gnu.org > Date: Tue, 19 Sep 2023 06:22:36 -0400 > > > 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. It isn't just about text properties and overlays. Even simple C-n requires us to march all the way between the position of point to the position that's below it on the screen. We must process each and every buffer position in-between, and perform a large portion of what redisplay does (specifically, its layout calculations, which require the metrics of every character we traverse) to find the character that is directly below point, so that we could move point there. All this because buffer text is a single unstructured string of bytes. If we want to speed up redisplay in such situations, we must get some help from the buffer text itself, so as not to have to redo all those layout calculations each and every time we need to convert buffer positions to screen coordinates or back.