GNU bug report logs - #73452
Code lens support in eglot

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 73452 <at> debbugs.gnu.org, federico.beffa <at> fbengineering.ch
Subject: bug#73452: Code lens support in eglot
Date: Wed, 25 Sep 2024 14:31:20 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Tue, 24 Sep 2024 22:01:02 +0100
> Cc: federico.beffa <at> fbengineering.ch, 73452 <at> debbugs.gnu.org
> 
> > What infrastructure would be needed?
> 
> It's not easy to describe, you'd have to be very familiar with how
> code lens work on VSCode and Visual Studio (I'm not).  It's a cross
> between Flymake and Eglot's custom inlay hints.
> 
> The lower-level infrastructure (buttons, overlays, jit-lock-register) exists
> and is probably enough for a decent experience (though there are
> the typical annoying flaws with overlays and jit-lock-register).  The problem
> is knowing how to tie this together in an sensible and robust infrastructure
> that Eglot (or other providers) can plug into.  An abstraction that will model
> something presumably more useful and practical than what is already
> available through other existing Emacs means (vc-* commands, M-x compile,
> Eglot code actions).

Then maybe someone could describe such an abstraction.

> Read the last parts of the discussion I linked to if you're
> interested.

I did, but couldn't answer my questions, because the discussion relies
heavily on VSCode features with which I'm not familiar and whose
descriptions I saw didn't clarify the issue.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.