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

Previous Next

Full log

Message #14 received at 73452 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73452 <at> debbugs.gnu.org, federico.beffa <at> fbengineering.ch
Subject: Re: bug#73452: Code lens support in eglot
Date: Tue, 24 Sep 2024 22:01:02 +0100

On Tue, Sep 24, 2024 at 4:48 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Cc: 73452 <at> debbugs.gnu.org
> > From: João Távora <joaotavora <at> gmail.com>
> > Date: Tue, 24 Sep 2024 15:26:55 +0100
> >
> > There is a discussion thread about this in the Eglot GitHub downstream tracker.
> >
> > https://github.com/joaotavora/eglot/pull/71
> >
> > The current consensus there is that the feature is not _that_ useful,
> > and that a clean implementation isn't really trivial since there is no
> > underlying Emcas support structure (like there is for documentation,
> > cross-referencing, diagnostics, snippets, etc)
>
> 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).  Read the last parts of the discussion I linked
to if you're
interested.

João

Previous Next

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