From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Wed, 08 Apr 2020 10:45:33 -0400 Message-ID: References: <20200403174757.GA8266@ACM> <20200404104553.GA5329@ACM> <07fe3b69-3ab2-3173-0696-cb17809e2b91@gmx.at> <83blo7v68b.fsf@gnu.org> <1845d7aa-9ae4-3d95-6a30-c7b1d8d8adec@gmx.at> <83a73qt6zs.fsf@gnu.org> <97c4254e-ff43-8402-3645-f713c408c245@gmx.at> <83y2r9syby.fsf@gnu.org> <20200405195753.GG5049@ACM> <542b48ba-4dfa-820f-ba50-4b147ab6d8e2@yandex.ru> <0a5f70aa-4985-8f8d-81d6-6ac4a60a94f9@yandex.ru> <838sj8sphk.fsf@gnu.org> <834ktwsmfw.fsf@gnu.org> <83imibqsmm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="119073"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: rms@gnu.org, emacs-devel@gnu.org, rrandresf@gmail.com, Dmitry Gutov , acm@muc.de, Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 08 16:46:35 2020 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 1jMByL-000UNV-FW for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 16:46:33 +0200 Original-Received: from localhost ([::1]:36968 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMBy1-0007Bb-02 for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 10:46:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53839) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMBxU-0006U5-Hx for emacs-devel@gnu.org; Wed, 08 Apr 2020 10:45:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMBxT-0002cx-0e for emacs-devel@gnu.org; Wed, 08 Apr 2020 10:45:39 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59424) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jMBxR-0002cC-JD; Wed, 08 Apr 2020 10:45:37 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B808081053; Wed, 8 Apr 2020 10:45:36 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 16C9180DDA; Wed, 8 Apr 2020 10:45:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1586357135; bh=UtJ/jUpN3BnXdKygFG9IEuMCDlObt8RoHYLeQxco/3o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cSyMzyry/8iJb/1BVNI/mDJ6g4V527enlPfDgc1I5bLHoNYyINAZZHaFsHc3CGlDM PWQjIh+h4hzs7k/uboM6cdY/TjJztr+A/zkgTYIELMhbhulOUR3dGwruQ2XMZSIgx7 TtA3Z53IBqAFp+jd+H/ZDxNjskSdmvp5PnZqYJY3SsdH+3jIkX23ouedm0Zf4E0Xga MMfuOKVmfgBDdRKfFJUmZMijhNoV085aYw+guM4Bne10+8Hz2nNuwkOfJW1+cdCNK0 21f0qwaR920Al2JPVmzD5LyyDNNiPu/ZytqHBzk53BFLLOOoKcqBFzoBAUz0AhrXbR UTtZlQokqVg/A== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9490D12068D; Wed, 8 Apr 2020 10:45:34 -0400 (EDT) In-Reply-To: (martin rudalics's message of "Wed, 8 Apr 2020 10:37:46 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:246672 Archived-At: > IIRC fontification can also modify text before the position where the > 'fontified' property changed to nil. It can do basically anything it likes, so yes, that can happen. That can also cause the display to be incorrect because the redisplay has already rendered that text. > Or is that wrong? It's not wrong, but if you *need* it, then you may have to do extra work to make sure it's handled correctly. E.g. jit-lock clients can tell jit-lock which part of the buffer they actually fontified by returning a value of the form `(jit-lock-bounds START . END)`. START can then find its way to the following code (under the name `loose-beg`): ;; The redisplay engine has already rendered the buffer up-to ;; `orig-start' and won't notice if the above jit-lock-functions ;; changed the appearance of any part of the buffer prior ;; to that. So if `loose-beg' is before `orig-start', we need to ;; cause a new redisplay cycle after this one so that the changes ;; are properly reflected on screen. ;; To make such repeated redisplay happen less often, we can ;; eagerly extend the refontified region with ;; jit-lock-after-change-extend-region-functions. (when (< loose-beg orig-start) (run-with-timer 0 nil #'jit-lock-force-redisplay (copy-marker loose-beg) (copy-marker orig-start))) -- Stefan