Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 21:13:24 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 16:09, Eli Zaretskii wrote:
> 
> > your contributions and efforts are greatly appreciated, but that's not
> > what I meant.  I meant leading the migration process to the
> > (allegedly) new and better tools, then assessing how well they fit us
> > and making whatever changes are needed, or concluding they failed the
> > tests.
> 
> Thank you, of course.
> 
> But I'm not sure I could lead anything in this process, given that we 
> can't seem to agree on the basic goals.

I don't know why you decided we don't agree on the goals.  I think we
do; the list of requirements for these tools was posted, and AFAIR was
agreed upon.

> > If you do a good job, and the tools are useful, they _will_ be used,
> > and then a buy-in might be a no-brainer.  We will see when we get
> > there.
> 
> There is no point in me doing either, if the catching issue is how other 
> developers find it possible (or not) to work with specific tools. 

Again, I don't understand how or why you arrived to that conclusion.
I don't think it is correct.

> Should we go through another round of listing bug trackers and voting, 
> or something?

What for?  We need tools that satisfy certain requirements, why does
it matter how they are called?  If we find a set of tools that can
support our requirements, at least most of the important ones, we
could try using them, and only then it will be known whether the
workflows are good enough and whether the features that are missing
are critical.

And voting is absolutely the worst method of getting anything
significant done around here.  If I used voting for decisions how to
implement bidi, I would still be discussing this on the (now defunct)
emacs-bidi list, instead of having a working implementation.

> >> Important for allowing more people participate in the conversations.
> > 
> > That's not the main goal of these tools, as far as the maintainers are
> > considered.
> 
> If collecting user feedback and communicating with users is not the main 
> goal, and reducing maintainers' workload is the priority, I guess we 
> should stop asking for more code to be contributed in Emacs.

Please don't exaggerate and don't consider this a zero-sum game.  We
want tools that facilitate feedback, but their primary goal is to
allow development and maintenance of Emacs.  That should be a
no-brainer, and I'm frankly astonished this is something that needs to
be argued about.  What would be the purpose of collecting user
feedback and communicating with users if we cannot efficiently apply
that to development and maintenance??

> At least as far as anything that can possibly live in ELPA is
> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let
> the developers use the trackers they are comfortable with, with
> maximum flexibility. The proverbial "lean core".

I'm not aware that ELPA packages are forced to use debbugs.  We accept
reports about them on debbugs, but don't enforce that, at least AFAIK.

> BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue 
> of Emacs 29.1 users having ts modes incompatible with the latest 
> grammars (they'd just upgrade Elisp code over ELPA).

Not true.  Moving a mode to ELPA doesn't solve that particular problem
(or any other one).  On the contrary: having those not bundled would
mean users don't have an OOTB solution, and would need to invent their
own wheels.  It also means the instructions about how to install the
relevant grammars would not have been in NEWS, so users would need to
discover that by themselves.  And the command we added to treesit.el
for installing the grammars would be missing as well.  Not to mention
the documentation in the user manual.

These are the immediate downsides of having a package outside of the
core.

> >> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's
> >> hard to argue that Emacs is more complex, or even comparable, to
> >> Firefox.
> > 
> > No, it isn't hard.  Compare the number of domains whose expertise we
> > need, that's the important aspect.
> 
> They would obviously have more.

Yeah, right.

The list of the kinds of domain expertise we need in Emacs was posted
in the past, most of it is not needed for those other projects.

> >> And if they reached this size in 20 years rather than 40, it's
> >> an evidence to better productivity rather than the opposite, right?
> > 
> > They have a Web browser, that's all.
> 
> Yeah, a program written in C/C++/Rust which contains an interpreter (and 
> multiple jit's) for a dynamic programming language and has most of its 
> interface written in it, supports user extensions in the same language, 
> support display of arbitrary files and has several related but different 
> mechanisms for guiding the visuals and the layout of said display. It 
> also supports bidi.

It's just a browser.  All the features you mention are used for Web
browsing.

> >> According to
> >> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/
> >> (article from 2017),
> >>
> >>     > 700 authors contributed code to Firefox over ~1 year
> >>
> >>     80 of them were volunteers, "contributors from all over the world".
> >>
> >> and by those 700 authors:
> >>
> >>     75,342 files changed
> >>     4,888,199 lines were added
> >>     6,886,199 lines were changed
> > 
> > Counting just "authors" and "contributors" doesn't tell enough, but at
> > least show the comparable numbers for Emacs, okay?
> 
> I figured you have said numbers at hand, more or less. But they must be 
> lower.

I'm not sure they will be lower.

> If you like I can try producing them, but what point would you be trying 
> to make?

My point is that Emacs maintenance is a much more complex and
difficult job than the job of those projects.

> The point I was trying to make that a big and complex project with many 
> contributors (bigger than ours, more complex than ours, with more 
> developers than here) can be well-served by a workflow that is rather 
> different from ours.

This remains to be shown, because the raw unanalyzed numbers you've
presented don't provide sufficient evidence.