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

[Harald Kirsch <pifpafpuf@gmx.de>]

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
>>