[Top][All Lists]

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

Re: PL support

From: Dmitry Gutov
Subject: Re: PL support
Date: Sat, 9 May 2020 21:44:56 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 09.05.2020 21:19, João Távora wrote:

Not many immediate "killer" advantages, Yuan Fu, but:

- eglot.el would be simplified, tho maybe only slightly.  That is good.

Splitting a program would simplify it? I'm somewhat skeptical so far.

- language specific quirks (that do exist despite LSP) would be dealt
   with in the corresponding mode, not Eglot, by using Eglot's
   existing interfaces.

That sounds fine, but then you'd have to convince major mode authors to set these settings. And educate them on what values they should use.

Considering you likely know more about C/C++ LSP servers than Alan, for example, that doesn't sound productive. And python-mode is unmaintained... js-mode hasn't seen a lot of dedicated development either. You get my drift.

- Eglot could grow _more_ programmatic interfaces for that
   to happen. It doesn't have them because it's the chicken and
   the egg.

We'll have to discuss those.

- More importantly, many bugs that target Eglot's UI but are actually
   Emacs's would come here. Discussing them in Github and hailing (mostly)
  Stefan and Dmitry there works, sort of, but it would be better if we used  the
   Emacs bug tracker (yes I know there are strong opinions on this).  But at
   the very least people like Eli and Richard would be able to participate
   regularly in those discussions, and provide insight that just doesn't
   reach the Github-sphere.

Umm. As a person with a fairly opinionated approach to package development yourself, I think you might underestimate certain downsides in sharing this responsibility like that.

And it doesn't look like Eli and Richard have a lot of free time to get into the particulars, or fix Eglot's bugs. I don't either (so far).

Let me give you an example: didn't your eglot-box thing end up being
an eldoc-box instead?  It should be in eldoc.el, it's a pretty good idea!
Well if eglot was in the core, you'd just automatically do it for eldoc.el
and  get help on how to do it from seasoned Elispers who hang around
here and not Github.

How would that help? Eldoc has a defined interface. If eglot-box could be based on that, it could just be considered for contribution on its own.

reply via email to

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