unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Filippo Argiolas <filippo.argiolas@gmail.com>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: "Felician Nemeth" <felician.nemeth@gmail.com>,
	emacs-devel@gnu.org, "Eli Zaretskii" <eliz@gnu.org>,
	"João Távora" <joaotavora@gmail.com>
Subject: Re: [NonGNU ELPA] new package: clangd-inactive-regions
Date: Sun, 3 Nov 2024 09:08:54 +0100	[thread overview]
Message-ID: <CAOdrLGLLYX54W1RrMGrS6ZQkqGDSp9=7He2eOnn_SrStg5Sbxw@mail.gmail.com> (raw)
In-Reply-To: <CADwFkmn+TaxvoMWaO3opbD+xSRzqZ9ont8TY4nx-8AbVVoZQhQ@mail.gmail.com>

On Sun, Nov 3, 2024 at 2:22 AM Stefan Kangas <stefankangas@gmail.com> wrote:
>
> Felician Nemeth <felician.nemeth@gmail.com> writes:
>
> > There is an open pull request by Slava Akhmechet in eglot-x that
> > implements a similar feature for clangd and ccls (which uses a differnet
> > LSP extension) [1].  There I wondered its compatibility with the
> > built-in hide-ifdef-mode.
> >
> > Slava originally sent the pull request to the Eglot's repository [2],
> > but João said "Eglot is, by design, only for LSP nor for extensions to
> > the protocol."
>
> I see the logic in João's arguments for wanting to limit eglot.el to the
> LSP standard only.  But then the natural question is: where does
> functionality covering LSP extensions belong?
>
> One option is to have separate packages for every LSP extension out
> there, or indeed a catch-all like eglot-x.el.  Maybe this is okay.
> However, does Eglot's design goals really mean that we will _never_ want
> these features in Emacs core?  I'm not so sure.
>
> This is why I'm proposing to submit the new clangd-inactive-regions
> package to GNU ELPA instead.  That way we could more easily integrate
> this into Emacs later (i.e. without having to worry about copyright
> assignments).  We would still need to figure some things out, of course,
> such as where this functionality goes: to some new `eglot-extras.el', to
> various major modes, or what.
>
> Regarding eglot-x.el, of which you Felician seems to be the only major
> contributor, I would actually say the exact same thing.  Why isn't this
> package on GNU ELPA?  I suggest that you to submit it.  :-)
>
> I'm copying in João, in case he has anything to add here.

Thanks everyone for the feedback!

Before creating this package I had some discussion about this with
João, don't remember if it was in debbugs or here.
His stance then too was that this was server specific and did not
belong in eglot.
The output from that discussion was adding a section into eglot
manual[1] that describes how to extend eglot using this very same use
case as an example.
If one wanted to just use the shadow face the code is all there and
it's the same I'm using.

Most of the code in my package is for the trick to darken the inactive
regions after fontification. But I'd say a proper opacity attribute
would be way more suited to emacs core than my ugly hack :-)

About GNU ELPA, I can look into it, could you send the paperwork
off-list? I'm ok with it as long as I don't need to involve my
employer.


1. https://joaotavora.github.io/eglot/#Extending-Eglot-1



  reply	other threads:[~2024-11-03  8:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-01  9:02 [NonGNU ELPA] new package: clangd-inactive-regions Filippo Argiolas
2024-11-02  9:13 ` Gerd Möllmann
2024-11-03  7:53   ` Filippo Argiolas
2024-11-03  8:43     ` Gerd Möllmann
2024-11-02 21:52 ` Stefan Kangas
2024-11-02 22:35   ` Felician Nemeth
2024-11-03  1:21     ` Stefan Kangas
2024-11-03  8:08       ` Filippo Argiolas [this message]
2024-11-03 15:07         ` Stefan Kangas
2024-11-04 17:36       ` Felician Nemeth
2024-11-03  5:59     ` Eli Zaretskii
2024-11-04 17:40       ` Felician Nemeth
2024-11-03  5:46   ` Eli Zaretskii
2024-11-04  5:34   ` Richard Stallman
2024-11-04  7:17     ` Filippo Argiolas
2024-11-04 12:02       ` Philip Kaludercic
2024-11-05  0:42         ` Filippo Argiolas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOdrLGLLYX54W1RrMGrS6ZQkqGDSp9=7He2eOnn_SrStg5Sbxw@mail.gmail.com' \
    --to=filippo.argiolas@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=felician.nemeth@gmail.com \
    --cc=joaotavora@gmail.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).