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. How about copy-on-write? Date: Thu, 21 Sep 2023 16:26:54 +0300 Message-ID: <831qerac81.fsf@gnu.org> References: <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <99e84ae7-b3aa-a009-5cb8-a75826343196@gutov.dev> <838r92cgxp.fsf@gnu.org> <837comcam8.fsf@gnu.org> <6946e6f0-c6ef-186c-35d4-c09935c05a07@gutov.dev> <83y1h1axtq.fsf@gnu.org> <87cyyd8487.fsf@localhost> <83il84c3p4.fsf@gnu.org> <87pm2bzu33.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39759"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 21 15:27:43 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 1qjJiX-000A6J-Uy for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Sep 2023 15:27:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjJhr-00039F-5z; Thu, 21 Sep 2023 09:26:59 -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 1qjJhp-000390-V0 for emacs-devel@gnu.org; Thu, 21 Sep 2023 09:26:58 -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 1qjJho-0005qT-Hp; Thu, 21 Sep 2023 09:26:56 -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=sNPbjwBqRJ+T85jFpxzqbKcsL6+BVv8eCkTU6ar9d2A=; b=L7K3jZjOj9PS 8kcfFdSU8K9QixxCMSL2pA2jOoi5jdp7RNBwOe30xNMDeYFzncSBpTJLHe+871ACFlNcAutkUA4To Sw2yx/irerm3IwiMi0RpYv2HzxmDL/gU34LgCP6dAEPGJDVuGc/pXw2wS7DR7jE0AgwwTlzZMJXP5 7Y4zcigOWjkc+x8soJgjMFzGxdgQOWUKO0oyW+Kffh9CIj8kmgUocwiPj0rkwnbJJm6JzTyTzgQSg DSg7i/s+z+JB5Fa8RRolGe3++ZnnCzd9UYQq4n0osVystYYyR/bn68hKCG20Pld2iSWV+v4mam/wm q+CsWJueHskVJSTvRO1nVQ==; In-Reply-To: <87pm2bzu33.fsf@localhost> (message from Ihor Radchenko on Thu, 21 Sep 2023 10:41:52 +0000) 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:310902 Archived-At: > From: Ihor Radchenko > Cc: dmitry@gutov.dev, acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org > Date: Thu, 21 Sep 2023 10:41:52 +0000 > > Eli Zaretskii writes: > > >> I believe that it is more a question of rewriting text property handling > >> into multiple segment trees dedicated to individual properties. > > > > Not as far as redisplay is concerned, no. The display engine _wants_ > > to look for the next change in any text property, because it processes > > them all "together". That is, it finds the buffer position where any > > of the text properties change, then hands that position to each of the > > known methods for handling property changes so that each one of them > > does its thing. > > This is... not what I know. May you please point me where in the code it > is done? compute_stop_pos finds the next "stop position" where properties (or something else of interest to redisplay) change, and when the iteration gets to that position, handle_stop calls the available handler methods to do their thing. The intervals of the text properties are examined by compute_stop_pos. > >From my previous experience, there separate processing of invisible > property and separate processing of composition property. But not > generic processing looking into all present text properties, including > the ones unrelated to redisplay. All of the handlers are called one after the other on every stop position we process. So the processing is sequential, but not "separate". In particular, the higher-level iteration routine (get_next_display_element), which detects when a stop position was reached, doesn't know and doesn't care which text property triggered the stop position; each called method checks if the current iteration position needs it to do something, and if not, immediately returns. That's how we support several properties that change at the same buffer position.