From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John ff Newsgroups: gmane.emacs.devel Subject: Re: Any expert on font-lock machinery able to provide some insight Date: Fri, 03 Jan 2025 14:42:10 +0000 Message-ID: <51feeaae-bb93-4a50-8ebc-0fbf7a9c0440@codemist.co.uk> References: <67d9db0a-ba0f-4164-83fd-796089a6e40b@gmx.de> <86ikqwgldg.fsf@gnu.org> <91114d5a-4af9-4ae1-b7c9-b673e5edf25e@gmx.de> <86cyh4gh0t.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----7CJ7W6JIFE2A32HJY8XU4PMOPDYRFJ" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1040"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Android Cc: Harald Kirsch , "Pranshu Sharma via Emacs development discussions." To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 03 15:45:38 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 1tTivg-00005K-GY for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jan 2025 15:45:36 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTitd-0002n3-8E; Fri, 03 Jan 2025 09:43:29 -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 1tTitY-0002kZ-3o for emacs-devel@gnu.org; Fri, 03 Jan 2025 09:43:24 -0500 Original-Received: from codemist.co.uk ([217.155.197.248]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTitW-0007CX-H0; Fri, 03 Jan 2025 09:43:23 -0500 Original-Received: from [172.16.4.31] by codemist.co.uk with esmtp (Exim 4.97.1) (envelope-from ) id 1tTisu-000000006cG-33Iq; Fri, 03 Jan 2025 14:42:44 +0000 In-Reply-To: <86cyh4gh0t.fsf@gnu.org> X-Referenced-Uid: 408719 Thread-Topic: Re: Any expert on font-lock machinery able to provide some insight X-Blue-Identity: !l=67&o=43&fo=2555&pl=4&po=0&qs=PREFIX&f=HTML&n=John%20ff&e=jpff%40codemist.co.uk&m=!%3AYWZmZmRhZTgtYWFhNS00NGEwLTgwNjktZDE2MGM0ZWIwYjBi%3ASU5CT1g%3D%3ANDA4NzE5%3AANSWERED&p=0&q=SHOW X-Is-Generated-Message-Id: true X-ACL-Warn: No reverse lookup Received-SPF: pass client-ip=217.155.197.248; envelope-from=jpff@codemist.co.uk; helo=codemist.co.uk X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-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.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:327628 Archived-At: ------7CJ7W6JIFE2A32HJY8XU4PMOPDYRFJ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 =E2=81=A3=E2=80=8B On 3 Jan 2025, 13:34, at 13:34, Eli Zaretskii wrote: >[Please use Reply All, to keep the list CC'ed=2E] > >> Da= te: Fri, 3 Jan 2025 13:44:04 +0100 >> From: Harald Kirsch >> >> Hi Eli, >> >> thanks for the explanation=2E >> >> On 03=2E01= =2E25 12:58, Eli Zaretskii wrote: >> =2E=2E=2E >> >> But it seems I am miss= ing another channel of information which >triggers >> >> font-locking too o= ften=2E >> > >> > Why does it bother you that it happens too often? >> >> = 1=2E I compare with elisp font-locking which is much less frequent=2E >> >= > 2=2E It is eglot-semtok, which does an LSP server call to get font-lock >= > information=2E It is quick enough and I wouldn't have noticed without >th= e >> logging, but it seems a waste nevertheless=2E >> >> >> With describe-= char I do see >> >> >> >> There are text properties here: >> >> fontifi= ed defer >> >> >> >> not going away=2E Can this point to the pro= blem? >> > >> > This should only happen with buffer positions that were not= yet >> > fontified=2E If the buffer position was already fontified, the v= alue >> > should be t=2E >> >> The buffer position was already fontified, = so I should not see this=2E >I >> might be doing something wrong so that th= e font-lock machinery >thinks, >> font-locking did not happen=2E The actual= fontification happens >> asynchronously (due to the server roundtrip), but= I thought I had >given >> the engine enough info pretending all is done=2E= I don't fully >understand, >> how the decision is made to fontify again=2E= >> >> Cheers >> Harald >> ------7CJ7W6JIFE2A32HJY8XU4PMOPDYRFJ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 3 Jan 2025, at 13:34, Eli Zaretskii <<= a href=3D"mailto:eliz@gnu=2Eorg" target=3D"_blank">eliz@gnu=2Eorg> w= rote:
[Please use Reply All, to keep the list CC'ed=2E]

 Date: Fri, 3 Jan 2025 13:44:04 +=
0100
 From: Harald Kirsch <pifpafpuf@gmx=2Ede>
 
 Hi Eli, 
 thanks for the explanation=2E
 
 On 03=2E01=2E25 12:58, Eli Za=
retskii wrote:
 =2E=2E=2E
 But it seems I am m=
issing another channel of information which triggers
 font-locking too o=
ften=2E

 Why does it bother you that it happens too oft=
en?
 
 1=2E I compare with elisp font-locking which is m=
uch less frequent=2E
 
 2=2E It is eglot-semtok, which does an LSP se=
rver call to get font-lock
 information=2E It is quick enough and I woul=
dn't have noticed without the
 logging, but it seems a waste nevertheles=
s=2E
 
 With describe-char I do see

 Th=
ere are text properties here:
     fontified            defer

 no=
t going away=2E Can this point to the problem?

 This sh=
ould only happen with buffer positions that were not yet
 fontified=2E  =
If the buffer position was already fontified, the value
 should be t=2E<=
br>
 
 The buffer position was already fontified, so I shoul=
d not see this=2E I
 might be doing something wrong so that the font-loc=
k machinery thinks,
 font-locking did not happen=2E The actual fontifica=
tion happens
 asynchronously (due to the server roundtrip), but I though=
t I had given
 the engine enough info pretending all is done=2E I don't =
fully understand,
 how the decision is made to fontify again=2E
 
=
 Cheers
 Harald

------7CJ7W6JIFE2A32HJY8XU4PMOPDYRFJ--