emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Eglot "inlay hints" landed


From: Stefan Monnier
Subject: Re: Eglot "inlay hints" landed
Date: Thu, 23 Feb 2023 14:27:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

> I'd love to switch over to the jit-lock implementation as it has
> potential to be much neater.  But I can't seem to get it to not
> over-request stuff. I attach the patch I've been trying, and it's
> clearly got some thinkos when you test it.  It doesn't help that
> `window-start` and `window-end` aren't -- apparently -- reliable
> when called from a jit-lock function.

Sorry, I have not followed the discussion, so I don't know what are
"inlay hints" nor how to test them.  What problem do you see what you
try your code?

> +(defvar-local eglot--inlay-hints-outstanding (cons nil nil)
> +  "Largest (BEG . END) window subregion not yet updated for inlay hints.")
> +
> +(defun eglot--update-hints (from to)
> +  "Jit-lock function for Eglot inlay hints."
> +  (cl-symbol-macrolet ((x eglot--inlay-hints-outstanding))
> +    (setq x (cons (min from (or (car x) most-positive-fixnum))
> +                  (max to (or (cdr x) 0))))
> +    (let ((w (get-buffer-window)))
> +      (trace-values "window:      " w)
> +      (trace-values "window-region:      " (cons (window-start w) 
> (window-end w)))
> +      (trace-values "outstanding: " eglot--inlay-hints-outstanding)
> +      ;  FIXME: this is NOT the correct condition to decide when to
> +      ;  request stuff from the server.
> +      (when (or (< (car x) (window-start w)) (> (cdr x) (window-end w)))
> +        (unwind-protect
> +            (eglot--update-hints-1 (car x) (cdr x))
> +          (setq x (cons nil nil)))))))

Why do you compare to `window-start/end`?

As you say, they're not reliably available during jit-lock, and that's
for fundamental reasons: jit-lock effects can change `window-start/end`.

But I can't see a good reason why you'd need to do such comparison:
the fact that jit-lock calls you is supposed to say "we need this for
redisplay", so you shouldn't need to double-check against window bounds.

Unless maybe you have `jit-lock-stealth-time` set to a non-nil value, in
which case indeed jit-lock will be called even on non-displayed areas of
the buffer, but it's arguably what the user (you in this case) asked for.

IOW, you should be able to skip `eglot--update-hints` altogether and use
`eglot--update-hints-1` directly (modulo catching errors and such maybe).


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]