From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: What's the best (i.e. least bad) way to re-redisplay? Date: Thu, 26 Aug 2021 09:49:33 -0400 Message-ID: References: <83r1egu2xx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="478"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Alan Mackenzie , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 26 15:51:16 2021 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 1mJFmm-000ASY-5J for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Aug 2021 15:51:16 +0200 Original-Received: from localhost ([::1]:55738 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJFml-00004w-52 for ged-emacs-devel@m.gmane-mx.org; Thu, 26 Aug 2021 09:51:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJFlL-0006Gb-DT for emacs-devel@gnu.org; Thu, 26 Aug 2021 09:49:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43090) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJFlE-0002DL-B9; Thu, 26 Aug 2021 09:49:45 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C4A8380855; Thu, 26 Aug 2021 09:49:36 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D9B168033D; Thu, 26 Aug 2021 09:49:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1629985774; bh=F8ylrso1sXq179pIgp37ts70rraz/eem17WkE27akS0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cZW/oG51woK493JPloD0LMmFm1b2hqw03lN0vO3LpgAJ4WXWahjEa+Yjv60Iz9bPY XM8SfLlsfJGwq7WEFWrd1eZGPTChrRBNGIvLDfHq+xxfa73K29V5SeGQBbmpRLUDi0 W4UEW+4x9bIVvdLIWhtRlgkH57+EhlChTJtpVlu+N/QQJamcQKZA7Hey/K8eYigisq uJWUw4FfQX4u+Fbw50fOztp/Em/orS5J4xrGIsjwiHUVnxTq+mHJVxsulpLYLPTe+b hd91sKs2JdmrjoB+UsWH/h/ovMaZ8DRuh540uCnjj+yPwOwz7RfNmyGx0OPZ/kxJBa OWd3J/EzqckCQ== Original-Received: from alfajor (unknown [104.247.244.135]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9FAF3120187; Thu, 26 Aug 2021 09:49:34 -0400 (EDT) In-Reply-To: <83r1egu2xx.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 26 Aug 2021 09:37:14 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:273028 Archived-At: >> > I think something along the lines of >> >> > (run-with-timer 0 nil >> > (lambda (buf) >> > (with-current-buffer buf (font-lock-flush))) >> > (current-buffer)) >> >> > is the cleanest that comes to mind. >> >> Thanks. That's probably cleaner than a direct use of >> jit-lock-force-redisplay. > > Why is it cleaner? jit-lock and font-lock include provision for the > fontification function to tell jit-lock what was the region actually > fontified, and that will trigger a call to jit-lock-force-redisplay in > a timer. Why not use an existing mechanism? That's indeed another option. I assumed that the situation is such that while fontifying region POS1..POS2 we discover a new type that forces the whole buffer to be refontified (or at least some region POS3..POS4), in which case it's best to use `font-lock-flush` and let this refontification happen lazily. But if indeed we can cheaply adjust the few places in the buffer that are affected without performing a full "refontify" it might indeed be a good idea to do that and adjust the `jit-lock-bounds` return value, but in that case we have to be sure that the new bounds indeed describe an area of the buffer that is now fully fontified, which is likely to be a problem because there is no reason to assume that the buffer outside of POS1..POS2 had already been fontified, so it may force us to eagerly fontify additional parts of POS3..POS4. Another option if we can cheaply adjust the few places in the buffer that are affected without performing a full "refontify", is to do those adjustments and then only force a redisplay but not a refontification. I think this can be done with something like: (run-with-timer 0 nil (lambda (buf) (with-current-buffer buf (put-text-property (point-min) (point-max) 'cc-dummy t) (remove-text-properties (point-min) (point-max) '(cc-dummy)))) (current-buffer)) -- Stefan