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

[Harald Kirsch <pifpafpuf@gmx.de>]

I think I found the problem.

If I wrap the face-adding code into with-silent-modifications, things
start to behave. Interpretation: without it the timer function doing the
font-locking is not under control of jit-lock so it sees the buffer
changes as a trigger to re-evaluate font-locking.

The confusing part was that I have with-silent-modifications in my
original code already. But what I have in fact is:

  (combine-change-calls start end
     ...
     (with-silent-modifications

which is (in hindsight obviously) the wrong order :-)

Thanks for your patience.

Harald


On 03.01.25 14:57, Harald Kirsch wrote:
> For better research I made a trivial example font lock function and call
> it, to simulate the async server round-trip, on a timer like so:
>
> ;;; -*- lexical-binding: t; -*-
>
> (defun eglot-semtok-request-fontification (&optional beg end loudly)
>    (message "front %s-%s" beg end)
>    (run-with-timer
>     0.1 nil
>     (lambda () (t-eglot-semtok-request-fontification beg end loudly)) ) )
>
> (defun t-eglot-semtok-request-fontification (&optional beg end loudly)
>    (message "timer %s-%s" beg end)
>    (save-excursion
>      (font-lock-unfontify-region beg end)
>      (goto-char beg)
>      (while-let ((mend (re-search-forward "[a-z]+\\(-[a-z]+\\)+" end t))
>                  (mstart (car (match-data))) )
>        (add-face-text-property mstart mend 'bold) ) ))
>
> (setq font-lock-defaults
>        '(nil nil nil nil
>              (font-lock-fontify-region-function
>               . eglot-semtok-request-fontification )
>              (font-lock-fontify-buffer-function
>               . eglot-semtok-request-fontification ) ) )
>
>
> - put into text file (easier to override font-lock)
> - M-x eval-buffer
> - M-x font-lock-mode
> - M-x font-lock-mode
> - insert a space near the top
> - move cursor
>
> See how for each cursor move the same front and timer messages are
> shown. When configuring the t-... function directly in setq and starting
> over, the extra font-lock calls are not seen.
>
> How would eglot-semtok-request-fontification need to change, short of
> actually fontifying everything, to lure font-locking into thinking all
> is fine, no need to run again shortly after?
>
> Harald.
>
>
> On 03.01.25 14:32, Eli Zaretskii 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
>>>