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

[Harald Kirsch]

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