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: region-based face-remapping Date: Wed, 10 Jan 2024 14:44:10 +0200 Message-ID: <83edepnysl.fsf@gnu.org> References: <83o7dupskh.fsf@gnu.org> <23BA0312-2129-49A5-A43F-900F789E8C54@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18266"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 10 13:45:34 2024 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 1rNXxd-0004QT-Kz for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Jan 2024 13:45:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNXwq-0003qA-Ev; Wed, 10 Jan 2024 07:44:44 -0500 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 1rNXwm-0003pd-8n for emacs-devel@gnu.org; Wed, 10 Jan 2024 07:44:41 -0500 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 1rNXwl-0007V1-FK; Wed, 10 Jan 2024 07:44:39 -0500 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=4OeHerqhsy3MaV7n3DkF77d7irMohBQ1lUWy5xmgmt4=; b=gLXO5Bsmq3kBAZfHVWyW sPbbj1oEl4e+3n//1KBZl/nvGCbFy0Ruompw/4O7vCr/xXRv1UNO9urExFn8sFA4AHS918mO+KjaE o9h1qTaWwoH/dZ/6aVuvJJBQXsqmo6hEuRaM/GuiOfGyhU55UJh2kv85GHPFN82P1bp2LpnXp54N+ 8LE9IKDnA1nk4SWGufOqcRgpQcz9qlfRM6Aw7h9KRGe2vrJgvr+WYvRGRcIsmCTcrp3MiXqsB6h73 Nyss4SQHizKWzj7TVaig2kWgy24dIHaMTkAwqObSqBCtT2um7+g1ASskNlBpuPxPvtmtDvnSuomlY 23sNxGavuU1aYQ==; In-Reply-To: <23BA0312-2129-49A5-A43F-900F789E8C54@gmail.com> (message from JD Smith on Tue, 9 Jan 2024 16:31:30 -0500) 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:314812 Archived-At: > From: JD Smith > Date: Tue, 9 Jan 2024 16:31:30 -0500 > Cc: Stefan Monnier , > emacs-devel@gnu.org > > Did you try to use jit-lock-register machinery? > > Maybe Stefan (CC'ed) will have better ideas. > > I haven’t. In my (limited) understanding and experience, all the font-lock apparatus is highly tuned to > after-change modifications. Here we need to (in addition) mark regions (old and new) as outdated, > even when the buffer hasn’t changed at all, just based on the movement of the (selected window’s) > point. I can know how to expand modified regions with `font-lock-extend-region-functions’, but I don’t > know how to inform font-lock that “even though you didn’t see changes, trust me, these regions are in > need of updating”. I would do this in a PCH, rate-limited by a timer. It is not true that jit-lock is based on editing changes. It uses a special text property to mark regions already fontified, so resetting that property will cause the corresponding region to be re-fontified on the next redisplay cycle. > Maybe it’s as simple as calling `font-lock-flush’ on those regions? If so, can you call font-lock-flush > multiple times in a row on overlapping regions without creating issues? Does font-lock-flush do the > right (JIT) thing, even when you mark a very large region? Yes, AFAIU. But it might be overkill for your case. > And (this is the big one) how do you handle two chef’s both with their spoons in the font-locking pot > at the same time? > > 1 Normal font-lock responding to changes in the buffer to refontify regions. > 2 PCH+timer marks regions for refontification when the buffer-modified-tick or treesitter > region-of-interest changes (the former because you can no longer trust that equal regions are in > fact equivalent). Don't worry about that, redisplay and jit-lock know how to deal with that. > Seem like there’d be a bunch of unnecessarily repetitive refontification in such a scheme. And > marking large regions with `font-lock-flush’ every 75ms as you type also seems problematic. That could be, but I'm quite sure this can be optimized if it works for your use case. > For disclosure, I’ve never used jit-lock-register, and personally find the font-lock documentation light > on details for implementing non-standard fontification scenarios such as this. That's why I asked Stefan to join this discussion. > That's exactly what JIT font-lock solves, right? Editing a buffer > changes the text, and thus the faces that need to be put on the text > change also. For example, something that was a comment can become > non-comment, or vice versa. Isn't what you describe similar (read: > identical), except that the faces themselves are different, i.e. not > font-lock faces? > > I guess so. The difficulty seems perhaps the other way around: updating font-lock JIT for both buffer > modifications and (potentially) point movement (simultaneously, without stepping on each other!). Again, don't worry about that. Once redisplay cycle starts, changes are basically frozen, so whatever was done in the buffer gets fontified. If there's a followup change, it will be fontified again.