emacs-devel
[Top][All Lists]
Advanced

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

Re: [NonGNU ELPA] new package: clangd-inactive-regions


From: Filippo Argiolas
Subject: Re: [NonGNU ELPA] new package: clangd-inactive-regions
Date: Tue, 5 Nov 2024 01:42:27 +0100

On Mon, Nov 4, 2024 at 1:02 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> Filippo Argiolas <filippo.argiolas@gmail.com> writes:
>
> > On Mon, Nov 4, 2024 at 6:34 AM Richard Stallman <rms@gnu.org> wrote:
> >>   > > It's an eglot extension that listens to clangd inactiveRegions
> >>   > > notifications and shades inactive code accordingly. It's useful to
> >>   > > highlight disabled code sections in a LSP aware way, honoring current
> >>   > > building options and defines.
> >>
> >> Does "inactive region" mean unreachable code?  I am guessin so.
> >>
> >> Is there a standard way for lamguage servers to report unreachable code?
> >> Could we make Emacs recognize that way?  Then eglot could handle it
> >> for any language, and it would not be specific to clangd.
> >
> > In this context it means unreachable code as disabled by the
> > preprocessor stage, e.g. code under a currently disabled ifdef branch.
> > LSP advantage here is providing knowledge about how a file is compiled
> > with proper build time flags and defines for current build
> > configuration.
> >
> > At the moment it's a clangd specific extension, there was some plan[1]
> > for standard LSP inclusion but I'm not sure it went anywhere.
> > Also, does this specific meaning make sense for non c/c++/preprocessed
> > languages?
>
> It might not be a bad idea to anticipate future standardisations, or
> other LSP servers supporting similar functionality, and branding the
> package as eglot-inactive-regions instead of the more specific
> clangd-inactive-regions (which also doesn't hint that it is eglot
> specific).
>

Never really liked the name but there was no way to convey everything
in a short name... eglot extension, specific to clangd, inactive
regions etc.
I never used ccls my self but I see from the PR linked by Felician
that ccls support for their skipped ranges extension would be already
easy enough to add.
So a rename might actually make sense.
Will think about it and report back!

Filippo



reply via email to

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