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

[Harald Kirsch]

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