From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: New Package for NonGNU-ELPA: clojure-ts-mode Date: Sun, 27 Aug 2023 07:26:55 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000006cd3d0603e1a141" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38768"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Dmitry Gutov , Danny Freeman , Stefan Kangas , emacs-devel , Manuel Uberti To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 27 08:25:05 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 1qa9Cr-0009q2-AZ for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 08:25:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qa9CO-0002mZ-Af; Sun, 27 Aug 2023 02:24:36 -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 1qa9CJ-0002mM-C0 for emacs-devel@gnu.org; Sun, 27 Aug 2023 02:24:31 -0400 Original-Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qa9CG-0004HH-Ds; Sun, 27 Aug 2023 02:24:31 -0400 Original-Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2bcfdadd149so15178011fa.0; Sat, 26 Aug 2023 23:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693117465; x=1693722265; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=87nER7AHc2TxlkEnkb5z77CpSBVj+NqWkkWKZVvO4HE=; b=NkXgIvn5uhobyPQhKDWYSanxxECmychJ1j8nW/UfJBDK68+U6U4BLm+5+kX8OzVdNk YyVqWDsAp0wYe5c84+L5tmM4cmeQEVBUJTYbQSPOuL2POoknIFWNNVKnNVrGHdm77u9+ t183UwGUPyTC1tqIhk98P2snK3HJXqwK3unXO5YJPgZ+yclt+LUqNXElN3e5tNjrRoS6 JesoFHdiQK/b0Em3wa6ptWVQZCXNNyKTKSqcfAfq0lUcb39LxV3fOz3OZpIktClUdH3w 9zQP9fyYcr9O5LMiUBe1p3WWNQg1IxJNmK8w7PM8n/chmELsC7QdQhk/icoBFxIR1Nho J5ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693117465; x=1693722265; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=87nER7AHc2TxlkEnkb5z77CpSBVj+NqWkkWKZVvO4HE=; b=H3j5h/xGcDkXOGCgLwSmFm4iJgbIQv4h81twxDrdlJ6V7jrxq8HTp/cLfZP9u+RUD/ ja7niCI2EAPJ6LOOsA/aHDPdeBkxwvga6deF/aEh3ey+yyqZ6Pw6Z4GcrpiQCFRBgQoR aNFW0eeS3td9m9s/UsZSol5eayc2xyvmt3VIPQ35krzkGkvNsLS1j+4H0wamCXS2iYcw icPbGBTBOBhPYd93yjyMu1Q359DBcOQlAQt3q9nQLWmot1FjdD012ICKpQY4tW3yMynQ 8pQVFh+dFa7QZkIaQa2XSHKLiKk294CKnG++TSU6/NmVU7D3T43zz98ev3wp9ANovZSv LvBQ== X-Gm-Message-State: AOJu0YwVrfwxB2wxb/pp1j3ZxAuFcGOkhFeUXTFuU/XHbi2ld+NQ/aw/ RNEV9XhbZb8V58IosvV2GkzBBN7p+S5MvWDSpEU= X-Google-Smtp-Source: AGHT+IGkyHvaRP9UasJHaHH/E11c1bHeOkBcs1iLIut3ykCu0uOdpdJJ62Brtafwe+9WFPymKvIhwOVupTyB78yvmFQ= X-Received: by 2002:a2e:2e08:0:b0:2bc:dfab:5dc8 with SMTP id u8-20020a2e2e08000000b002bcdfab5dc8mr7705979lju.37.1693117464364; Sat, 26 Aug 2023 23:24:24 -0700 (PDT) In-Reply-To: <87a5udk1co.fsf@posteo.net> Received-SPF: pass client-ip=2a00:1450:4864:20::235; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x235.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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:309308 Archived-At: --00000000000006cd3d0603e1a141 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 26, 2023, 21:15 Philip Kaludercic wrote: > Eli Zaretskii writes: > > >> Date: Sat, 26 Aug 2023 21:52:31 +0300 > >> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org, > >> manuel.uberti@inventati.org > >> From: Dmitry Gutov > >> > >> On 25/08/2023 08:42, Eli Zaretskii wrote: > >> > IME, the development model of Emacs is an important reason why Emacs > >> > is still alive and kicking almost 40 years since it was first > >> > developed. And important major modes in Emacs are alive and kicking > >> > with it. So inclusion in Emacs and the pains of adjusting to a > >> > different development model are justified if one wants the major mod= e > >> > to remain alive for many years to come. Something to think about, I > >> > guess. > >> > >> Or the longevity stems from other reasons (e.g. good fundamental ideas= , > >> unique proposition, being part of the original GNU system, ...), and > the > >> development process is the reason the current user base is a fraction > of > >> even Vim's (not to mention popular commercial offerings). > >> > >> Just an alternative POV to consider. In truth, could be a little of > both. > > > > Mine wasn't a POV, it was an observation based on many years of > > watching the development and being part of it. > > Correct me if I am wrong: This seems to be related to the fact that the > GitHub-model (thought it probably precedes it) of development has > motivated more and more individuals to maintain packages, instead of > organisations like GNU, Apache, etc. Or at least I understand that if > there is a collective effort behind maintaining the components of a > system, contributors can come and go without a package being abandoned > -- this is especially true for Emacs due to the extensive > introspectability. But it appears this reaches a limit, if a component > is too complex (CEDET was mentioned as one example, and if Jo=C3=A3o were= to > suddenly loose interest in contributing to Emacs, something similar > might happen to Eglot as well). > I don't know if you've ever compared the source of both packages, but in terms of complexity Eglot pales in comparison to CEDET This is by design, of course. Also, many moons ago, circa Emacs 22, I actually tried to get CEDET working for a full C++ dev environment in a company setting. I went through a lot of its code doing changes (never published). I was a different programmer but I think I would still find it just as impenetrable today. Things are much better -- radically better -- these days. Not thanks to Eglot but thanks primarily to LSP and the continued quality work on half-decent protocols for connecting it to our UI. Things like like xref, project, eldoc, flymake, company, etc. I'm a bit perplexed why you picked me as the star of "what if he were to disappear?" but I guess I'm as good a candidate as Michael, Lars, Dmitry or so many others. So let me then offer my 2c on what is fast becoming the customary yearly round of "whither Emacs?". Whenever GitHub looks to be the essential catalyst of vibrant and effective software, look again. The reason why so many projects looks like be they're going a million km an hour is because they are, and they're accumulating loads of bloat and technical debt in under-reviewed design decisions just because it is so easy to press a green button to merge something. You may as well have ChatGPT at the helm. When they aren't, it's because a small group of devs is actively curating and protecting the project, or because GitHub in itself doesn't bring about any game-changing dynamic, such as happened with SLIME which -- much like CL itself -- was half-moribund ca 2012 when I helped move it to GitHub (with similar illusions to many others about its redemptive power) and is half-moribund today (which is another word for "reasonably stable" in the end). So the lure of the "GitHub-model" is deceptive. More likely some devs of some successful projects there are just sticking to it because they happen to already know it very well and resist changing. Just like many devs in "our" camp. More likely those "GitHub model" devs just don't dig the vibe around these parts that much -- perfectly legitimate -- but are a bit afraid to say so, so they say it's the CA requirement and the patches model. After all, this mailing list, for all the talk of obsolete mails etc, is very heavily participated and even more heavily read. Just the fact of having one's work scrutinized in such a big forum is not to everyone's liking. And that's perfectly legitimate, too. Developing a package outside Emacs is a liberating experience by comparison. Inside, there is a completely new set of concerns, completely independent of the forge you use. The format of manuals, coding style, commands you can and cannot add, even the upgrade options you offer to your user base are affected. As I've recently learned, moving a package from the outside to the inside is a bit like getting married: you better be prepared to give some things up and fight actively for others. You have to love Emacs very much to make it work ;-) In my personal case I find no significant difference in working with either model. I find certain GitHub discussions and issue threads just as pleasant or toxic as the things I find here. I find email reviews of patches no more complicated than those sophisticated boxes. Trivial patches to typos and stuff are indeed a little harder to apply here compared with the the big green button. But then trivial patches aren't the things moving a project forward anyway. I could switch to SourceHut, of course, or anything -- including GitHub. It won't make that big of a difference I think. Jo=C3=A3o > --00000000000006cd3d0603e1a141 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 26, 2023, 21:15 Philip Kaludercic= <philipk@posteo.net> wrote:
Eli Zaretskii <eliz@gnu.org> write= s:

>> Date: Sat, 26 Aug 2023 21:52:31 +0300
>> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@g= nu.org,
>>=C2=A0 manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>= ;
>>
>> On 25/08/2023 08:42, Eli Zaretskii wrote:
>> > IME, the development model of Emacs is an important reason wh= y Emacs
>> > is still alive and kicking almost 40 years since it was first=
>> > developed.=C2=A0 And important major modes in Emacs are alive= and kicking
>> > with it.=C2=A0 So inclusion in Emacs and the pains of adjusti= ng to a
>> > different development model are justified if one wants the ma= jor mode
>> > to remain alive for many years to come.=C2=A0 Something to th= ink about, I
>> > guess.
>>
>> Or the longevity stems from other reasons (e.g. good fundamental i= deas,
>> unique proposition, being part of the original GNU system, ...), a= nd the
>> development process is the reason the current user base is a fract= ion of
>> even Vim's (not to mention popular commercial offerings).
>>
>> Just an alternative POV to consider. In truth, could be a little o= f both.
>
> Mine wasn't a POV, it was an observation based on many years of > watching the development and being part of it.

Correct me if I am wrong: This seems to be related to the fact that the
GitHub-model (thought it probably precedes it) of development has
motivated more and more individuals to maintain packages, instead of
organisations like GNU, Apache, etc.=C2=A0 Or at least I understand that if=
there is a collective effort behind maintaining the components of a
system, contributors can come and go without a package being abandoned
-- this is especially true for Emacs due to the extensive
introspectability.=C2=A0 But it appears this reaches a limit, if a componen= t
is too complex (CEDET was mentioned as one example, and if Jo=C3=A3o were t= o
suddenly loose interest in contributing to Emacs, something similar
might happen to Eglot as well).

I don't know if you've ever compared= the source of both packages,=C2=A0
but in terms of = complexity Eglot pales in comparison to CEDET=C2=A0
= This is by design, of course.=C2=A0 Also, many moons ago, circa Emacs 22,= =C2=A0
I actually tried to get CEDET working for a f= ull C++ dev environment=C2=A0
in a company setting.= =C2=A0 I went through a lot of its code doing changes
(never published).=C2=A0 I was a different programmer but I think I=C2=A0=
would still find it just as impenetrable today.

Things are much better -- r= adically better -- these days.=C2=A0 Not=C2=A0
thank= s to Eglot but thanks primarily to LSP and the continued
quality work on half-decent protocols for connecting it to our
UI. Things like like xref, project, eldoc, flymake, company= ,=C2=A0
etc.

I'm a bit perplexed why you picked me as the star of "= what if=C2=A0
he were to disappear?" but I gues= s I'm as good a candidate as
Michael, Lars, Dmit= ry or so many others.

So= let me then offer my 2c on what is fast becoming the customary=C2=A0
=
yearly round of "whither Emacs?".=C2=A0 Wheneve= r GitHub looks to be the
essential catalyst of vibra= nt and effective software, look again.=C2=A0
The rea= son why so many projects looks like be they're going a million
km an hour is because they are, and they're accumulating= loads of=C2=A0
bloat and technical debt in under-re= viewed design decisions just=C2=A0
because it is so = easy to press a green button to merge something.=C2=A0=C2=A0
You may as well have ChatGPT at the helm.
=
When they aren't, it's because a small = group of devs is actively=C2=A0
curating and protect= ing the project, or because GitHub in itself=C2=A0
d= oesn't bring about any game-changing dynamic, such as happened with=C2= =A0
SLIME which -- much like CL itself -- was half-m= oribund ca 2012 when=C2=A0
I helped move it to GitHu= b (with similar illusions to many others about=C2=A0
its redemptive power) and is half-moribund today (which is another word=C2= =A0
for "reasonably stable" in the end).

So the lure of the "= GitHub-model" is deceptive. More likely some devs of=C2=A0
some successful projects there are just sticking to it because = they happen=C2=A0
to already know it very well and r= esist changing.=C2=A0 Just like many devs=C2=A0
in &= quot;our" camp.=C2=A0 More likely those "GitHub model" devs = just don't dig=C2=A0
the vibe around these parts= that much -- perfectly legitimate -- but are=C2=A0
= a bit afraid to say so, so they say it's the CA requirement and the=C2= =A0
patches model.

After all, this mailing list, for all the talk of obs= olete mails etc,=C2=A0
is very heavily participated = and even more heavily read.=C2=A0 Just the fact
of h= aving one's work scrutinized in such a big forum is not to everyone'= ;s=C2=A0
liking.=C2=A0 And that's perfectly legi= timate, too.=C2=A0 Developing a package
outside Emacs is a libera= ting experience by comparison.=C2=A0 Inside, there
is a completel= y new set of concerns, completely independent of the forge=C2=A0
= you use.=C2=A0 The format of manuals, coding style, commands you can=C2=A0<= /div>
and cannot add, even the upgrade options you offer to your user b= ase
are affected. =C2=A0 As I've recently learned, moving a p= ackage from=C2=A0
the outside to the inside is a bit like getting= married: you better=C2=A0
be prepared to=C2=A0 give some things = up and fight actively for others.=C2=A0=C2=A0
You have to love Em= acs very much to make it work ;-)

In my personal case I find no significant difference in working with=C2=A0=
either model.=C2=A0 I find certain GitHub discussio= ns and issue threads
just as pleasant or toxic as the things I fi= nd here.=C2=A0 I find email
reviews of patches no more complicate= d than those sophisticated
boxes.=C2=A0 Trivial patches to typos = and stuff are indeed a little=C2=A0
harder to apply here compared= with the the big green button.=C2=A0 But=C2=A0
then trivial patc= hes aren't the things moving a project=C2=A0
forward anyway.= =C2=A0 I could switch to SourceHut, of course, or anything=C2=A0
= -- including GitHub.=C2=A0 It won't make that big of a difference I thi= nk.

Jo=C3=A3o
--00000000000006cd3d0603e1a141--