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: rmsbolt.el [Was: Colorful line numbers] Date: Sat, 23 Jul 2022 18:52:01 +0300 Message-ID: <834jz7j07y.fsf@gnu.org> References: <87leslpow2.fsf@gmail.com> <83ilnpl8e0.fsf@gnu.org> <874jz9peq0.fsf@gmail.com> <837d45l6ge.fsf@gnu.org> <87zgh1nyo6.fsf@gmail.com> <831qudl1k3.fsf@gnu.org> <87v8rpntiv.fsf@gmail.com> <83sfmtjjy8.fsf@gnu.org> <87fsitnpxd.fsf@gmail.com> <83k085jgxr.fsf@gnu.org> <835yjojr0f.fsf@gnu.org> <87pmhwmat0.fsf@gmail.com> <83ilnoi0ro.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15490"; mail-complaints-to="usenet@ciao.gmane.io" Cc: joaotavora@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 23 17:52:54 2022 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 1oFHQz-0003st-DZ for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jul 2022 17:52:53 +0200 Original-Received: from localhost ([::1]:42428 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFHQy-0008Ce-3c for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jul 2022 11:52:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFHQD-000751-2L for emacs-devel@gnu.org; Sat, 23 Jul 2022 11:52:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40898) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFHQC-0003oI-P5; Sat, 23 Jul 2022 11:52:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=N+6AOONnhjsGVp245L1PPVttZ/mEV3rtEIatmKkzqP8=; b=kWhpeOaIkc2/3wxOGPEP +56am/FxSbbfjMahIsvRho04awLXcE66V25OfvxWEd211C3IBVYbP8m7s6nD72qsw9DaZ7eElzA6X 2exLTHy2L39e+trrPp0J9T2tQT7CgyNIT2SvFRRHnpXmW3Sdz/2lxZA71G8x4jqpyid9JJy8ScAAC AlK0miEb8MTIDcSVEzfAd5MYD4ygSQHn2hWgzzHzC0tNd4C7AUBwQkbUNbp/Q3hFjN4bld2J6RnXH wRsxJfi/Slf3dxyQVM1NEUFuUg65xGggREU5Aalwj8kxwQd4ew3ojeQlNX48Nc20fbnzVDr92vUFe Pr8qpTcCEAIsvQ==; Original-Received: from [87.69.77.57] (port=2893 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFHQC-0003AP-7t; Sat, 23 Jul 2022 11:52:04 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 23 Jul 2022 10:43:21 -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" Xref: news.gmane.io gmane.emacs.devel:292541 Archived-At: > From: Stefan Monnier > Cc: João Távora , > emacs-devel@gnu.org > Date: Sat, 23 Jul 2022 10:43:21 -0400 > > > The big difference from my POV is that text properties slow down > > redisplay code > > If that's indeed a problem, then maybe we should provide "non-display > text-properties". I.e. text-properties which do not influence the > display, so we can store them in a parallel interval tree That's quite a complication. For starters, how to make sure the same property doesn't get stored in both trees? Next, redisplay aside, most if not all properties that are important for redisplay are also important to Lisp, and so Lisp programs will now have to look at two interval trees. > (tho > we'd have to check whether the source of the slowdown is the interval > tree itself or the length of the `plist`s stored in its nodes, so maybe > we could have a single tree but with two `plist` fields, one for > display-related properties and the other for non-display-related > properties). The immediate source of slowdown is that the display iterator stops at every position where the properties change, and runs all of its "handle stop-point" handlers, each one of which examines the properties it handles (fontified, face, invisible, and display). For what we do with the tree and the properties we find, see compute_stop.