Re: Eglot "inlay hints" landed

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Mostly the fact that it's operating on a separate timer, but one
> that is directly correlated to jit-lock-context-time.

But that's because you're willing to wait for the context refresh to do
your own.

> So the bookkeeping and the coalescing of the small+large jit chunks
> should be provided by the jit infrastructure instead.

So far, you're the first to need such a thing.  In my experience the
needs for "jit display refresh" can be fairly subtly different, so it's
not clear how generally useful your approach would be.  Maybe we could
provide some shared infrastructure to maintain a "coalescing set of
buffer regions", but if so, I suspect that it wouldn't need to be tied
to `jit-lock.el`.

Also, I'm not sure it gives exactly the info you need/want:
I suspect that in some languages you can have:

   foo (x)
   ...
   function foo (bar : Int)

so that changing the `foo` definition will need to update the inlay on
the call to `foo` that is earlier in the buffer, hence jit-lock-context
refresh won't be sufficient and you'll need to force your own refresh.
[ I think jit-lock would benefit from being able to flush a particular
  backend's without forcing all of the backends at the sane time.  ]

> And then no extra timer or logic would be needed.

You mean you'd integrate it into `jit-lock-context`?
Maybe that could be done.

> Can we make jit-lock.el a :core ELPA package?

I have no opinion on that.


        Stefan