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: Any expert on font-lock machinery able to provide some insight Date: Fri, 03 Jan 2025 13:58:03 +0200 Message-ID: <86ikqwgldg.fsf@gnu.org> References: <67d9db0a-ba0f-4164-83fd-796089a6e40b@gmx.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12521"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Harald Kirsch Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 03 12:58:57 2025 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 1tTgKP-00039d-Ez for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jan 2025 12:58:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTgJj-00008w-PO; Fri, 03 Jan 2025 06:58:16 -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 1tTgJb-00006y-Ro for emacs-devel@gnu.org; Fri, 03 Jan 2025 06:58:07 -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 1tTgJb-00045s-BH; Fri, 03 Jan 2025 06:58:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=IUYPLC6uBXCBBt17yGdxidA2WWSEEluen/AnuKqW96Y=; b=MiGX9hR/ACMc Rs96EmlXY1rrHyZWwJKa3FLHnrWd/gPCTmP6+1mC2V0G1I7nD/AgColY0zFCayXXOTXBBgsVZlygC FhFkyqKHLyjzM7sgn/+zEuJMo2ja1LTNga3No5afQ03K1nksWoDVj7SBX+6FkN+qKfsiXaeUhth8E 24YeBV2cNiHwcXQ31D/XEWV7kGwUFCPiq4E/7itlmuURaHwSaXzIH0P+yo52ClXRGdDjWVA+EsZ4N LXiZ802mZGEHUOYdb5TJOOi0ljoSjiv4MCbuLqR5G+ecZWpLNN2gXFNDz4PLYMcKu59TB90e+2muS mJa4+fdGlGkjIYWGbmuuXw==; In-Reply-To: <67d9db0a-ba0f-4164-83fd-796089a6e40b@gmx.de> (message from Harald Kirsch on Fri, 3 Jan 2025 11:26:11 +0100) 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:327623 Archived-At: > Date: Fri, 3 Jan 2025 11:26:11 +0100 > From: Harald Kirsch > > Hi font-lock experts? > > I am working on a font-lock function and see it called by the jit-lock > timer at weird times. > > I see a normal font-lock function call after a change, for example when > inserting a character. But then I see > > - calls when moving the cursor (no scroll) > - when setting the mark > - when moving the mouse into **another** frame > - when moving the mouse into yet **another** frame This is expected. Lisp programs sometimes need to make layout calculations for some reason. For example, when you move the cursor with C-f, Emacs needs to know the buffer position that corresponds to the character to the right of the previous one. Since you can have several different faces and fonts in a buffer, the answer to that question needs to execute some of the layout code that is part of the display engine, and that will call jit-lock if the corresponding region of the buffer text was not yet fontified. > I understand that when the function does not return > > (jit-lock-bounds beg . end) > > jit-lock assumes the region was fontified just fine. For completeness I > also added the an explicit (jit-lock-bounds beg . end) return to my > font-lock function. Same behavior. > > But it seems I am missing another channel of information which triggers > font-locking too often. Why does it bother you that it happens too often? > With describe-char I do see > > There are text properties here: > fontified defer > > not going away. Can this point to the problem? This should only happen with buffer positions that were not yet fontified. If the buffer position was already fontified, the value should be t.