From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Text Properties And Buffer Modification Date: Thu, 06 Dec 2018 21:16:57 +0200 Message-ID: <83a7li79ee.fsf@gnu.org> References: <83y3948ov2.fsf@gnu.org> <87wooofnqf.fsf@fastmail.fm> <83o9a08jfq.fsf@gnu.org> <834lbr95nq.fsf@gnu.org> <5C082139.6060802@gmx.at> <831s6v94e9.fsf@gnu.org> <5C08E6E2.6080703@gmx.at> <83lg536mhp.fsf@gnu.org> <5C08F58F.5000004@gmx.at> <83k1kn6jau.fsf@gnu.org> <5C096E92.5000804@gmx.at> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1544124161 27817 195.159.176.226 (6 Dec 2018 19:22:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 6 Dec 2018 19:22:41 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 06 20:22:36 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gUzEJ-00077f-2k for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2018 20:22:35 +0100 Original-Received: from localhost ([::1]:42629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUzGM-0007sn-Uu for ged-emacs-devel@m.gmane.org; Thu, 06 Dec 2018 14:24:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUzGE-0007oN-2P for emacs-devel@gnu.org; Thu, 06 Dec 2018 14:24:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gUz8t-0000Ii-IH for emacs-devel@gnu.org; Thu, 06 Dec 2018 14:17:03 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58324) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gUz8t-0000Id-E3; Thu, 06 Dec 2018 14:16:59 -0500 Original-Received: from [176.228.60.248] (port=1281 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gUz8s-0007My-Sn; Thu, 06 Dec 2018 14:16:59 -0500 In-reply-to: <5C096E92.5000804@gmx.at> (message from martin rudalics on Thu, 06 Dec 2018 19:46:42 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231692 Archived-At: > Date: Thu, 06 Dec 2018 19:46:42 +0100 > From: martin rudalics > CC: monnier@iro.umontreal.ca, emacs-devel@gnu.org > > > The optimization I had in mind is try_window_id. You will see there > > that this optimization is disabled if overlays were changed, but not > > if the buffer (including text properties) was changed. you will also > > see there that buffer-modification tick is used there to update the > > unchanged text at beginning and end of the buffer when necessary. > > This must be the > > if (w->last_overlay_modified != OVERLAY_MODIFF) > GIVE_UP (200); > > form. I clearly missed that. That's one of them. The other is the snippet that begins with if (MODIFF > SAVE_MODIFF > IIUC try_window_id is based on the idea that typing should be fast > (that is, cause no excessive redisplay) as long as it does not happen > within an overlay. Not sure I agree with this interpretation. My mental model of try_window_id was that it attempts to reuse what is already on display by scrolling parts of the displayed stuff, and then inserting/deleting a few lines that have changed. It determines which parts of the display could be reused by analyzing where are the changes in the buffer relative to the displayed portion. How did we arrive at the situation where only some lines need to be changed is immaterial, and in general is not by typing, quickly or otherwise. try_window_id gives up if overlay changed because it finds the portions of the displayed text to be reused by looking at buffer text, and overlays invalidate the assumption that only buffer text determines what's on screen. > But why do we optimize changes of text properties as well? I'm not sure I understand the question. What do you mean by "optimize changes of text properties"? > This is one of those I looked at and found no difference between > overlay and text changes. Now the former of these > > w->last_modified = accurate_p ? BUF_MODIFF (b) : 0; > w->last_overlay_modified = accurate_p ? BUF_OVERLAY_MODIFF (b) : 0; > > is checked by try_window_id as > > if (w->last_modified == 0) > GIVE_UP (6); > > and the latter is needed by the check I cited above. But is there an > additioal twist? Since we rejected the case where overlays changed, we don't need to check it again. In general, the above condition means that the window's glyph matri might not be up to date, so we cannot safely reuse it.