From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode Date: Sun, 27 Aug 2023 21:46:00 +0300 Message-ID: <83zg2cias7.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <87a5uw9ivs.fsf@posteo.net> <87ttt42gna.fsf@dfreeman.email> <87wmy080kn.fsf@posteo.net> <83v8djcydl.fsf@gnu.org> <87350ndquw.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <83ledwk4xi.fsf@gnu.org> <76ecf629-a41a-f6e4-f661-2ef926326d6c@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35481"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 27 20:47:12 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qaKn1-000909-Qh for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 20:47:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaKmN-0001F3-HI; Sun, 27 Aug 2023 14:46:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaKmK-0001Ej-TQ for emacs-devel@gnu.org; Sun, 27 Aug 2023 14:46:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaKmJ-0007i2-U3; Sun, 27 Aug 2023 14:46:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DaKbEY8XpvYjjmmyaBFscUsJCwr0YjIeNusrcqKtAuU=; b=MxV5lI3gEy5o LCAnPWFkVXkmPXTEYC2cvGHdbWKzjh4J2WcsCsTe/nRSUTFzHhVlruKJL+iCTO+FUilq00OZxNh9m uNYQ5gC0JZJLhSaNxfGrxgUKmTXlhWGpBa2vowcA4WuqPtC3s2v+O1CP3h2oNk31jVjZYQNJFbeNL JzZMVbnh65y66CBBlRVAo02EQkYU5WUydHkrTR//KHRMyuU30zJ7UTuNqbwV7zTDoWsJS6E8jOMhL sMIymUSPIKnp7PRctek9jz7z2WLwtsR+2c9GjSn5s7iuItc5CU0AfwJ1VB5KegpbnctjCdduu4xxg 8ykU89x5RqeNsrbER5DGJQ==; In-Reply-To: <76ecf629-a41a-f6e4-f661-2ef926326d6c@gutov.dev> (message from Dmitry Gutov on Sun, 27 Aug 2023 21:13:24 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309367 Archived-At: > 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 > > 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.