Re: Any expert on font-lock machinery able to provide some insight

[John ff <jpff@codemist.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]



⁣​

On 3 Jan 2025, 13:34, at 13:34, Eli Zaretskii <eliz@gnu.org> wrote:
>[Please use Reply All, to keep the list CC'ed.]
>
>> Date: Fri, 3 Jan 2025 13:44:04 +0100
>> From: Harald Kirsch <pifpafpuf@gmx.de>
>>
>> Hi Eli,
>>
>> thanks for the explanation.
>>
>> On 03.01.25 12:58, Eli Zaretskii wrote:
>> ...
>> >> 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?
>>
>> 1. I compare with elisp font-locking which is much less frequent.
>>
>> 2. It is eglot-semtok, which does an LSP server call to get font-lock
>> information. It is quick enough and I wouldn't have noticed without
>the
>> logging, but it seems a waste nevertheless.
>>
>> >> 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.
>>
>> The buffer position was already fontified, so I should not see this.
>I
>> might be doing something wrong so that the font-lock machinery
>thinks,
>> font-locking did not happen. The actual fontification happens
>> asynchronously (due to the server roundtrip), but I thought I had
>given
>> the engine enough info pretending all is done. I don't fully
>understand,
>> how the decision is made to fontify again.
>>
>> Cheers
>> Harald
>>

[-- Attachment #2: Type: text/html, Size: 2541 bytes --]