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 mode > >> > 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ão 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ão >