[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: Sun, 10 May 2020 01:00:17 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 09.05.2020 23:25, João Távora wrote:

problem: everybody has to read every bug report and every commit message.
This is good.  I for one would like to spend a lot less time on Github.
Maybe less happy later to see people complaining about some problems in
Eglot on Twitter, Reddit, their blogs, etc.

I don't use those.  People know where to reach me.  If you frequent
those places, tell them I'm an email away.

I certainly don't frequent *all* of these places.

If they prefer to complain
in public in places I don't frequent, how is that my fault?

You could just go away and do nothing, and any bug reports still wouldn't be "your fault" (we promise NO WARRANTY, after all).

But Emacs would be poorer for it.

Really? Am I breaking backward compatibility all the time in Emacs?
Not really. But that's the only conceptual advantage I could see:
changing things in tandem. To *not* break things, at least for me,
packages have to be considered separately... and then having them in the
same repo is not so big an advantage.

In any case, it's not my main demotivator. Increased debbugs and
emacs-diffs traffic is. I'd rather much work on code that sorting
through email not related to me. There is nothing at all personal in this.

Huh? Are you saying we make too many commits to Emacs?
Then make an email filter for emacs-diffs that checks the files touches,
surely you can do that. Same for debbugs.

I wouldn't say I can. It's especially not easy with the set of packages I take interest it being more than a handful of files already.

Don't we have tests? Don't we have a (crude) namespacing system
for those libraries?  Don't we have Eli, the ever-vigilant? And Stefan
and everybody else?  And weren't you the one the one who told me
not to worry about that when refactoring Flymake?

Eli who hasn't found time to try out Eglot yet. Same for Stefan, I imagine.

I thought you were concerned about protecting xref and eldoc and such.
so what has that got to do with it?

You misunderstood me, then. Thought I clarified that in subsequent messages.

Going back to xref and project.el, for instance, it wouldn't be
sufficient to submit a patch and, in the explanation, assume my
familiarity with Eglot's code.  So I kind of doubt it will help you a lot.

It wouldn't be indeed.  And it would not be necessary, either. This is
how it goes.  I tell you: "we need this interface in eglot.el, here is a
patch that opens it.  And you check it on its merits. And you get to
see it in action, and compiled in the same test run, even.". It's
really standard stuff.

Like we do now already, right?

? > https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00415.html

Yup, it was a big rewrite, and Flymake was not used as much as e.g.
Eldoc is. I'm not saying you can never break backward compatibility,
just that you *usually* cannot break it.

But I _didn't_ break it, is what I'm saying (in fact flymake-proc.el
should still work as far as I can tell) I'm just pointing out you weren't
as concerned about it then, to the point of encouraging me not to
worry about it.

I'm saying the backward compatibility concerns and the necessity to consider of packages on their own pretty much negate the ability to make changes in concert. That's my view, of course.

reply via email to

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