Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01968.html
From: Po Lu
Date: Tue, 21 Dec 2021 09:06:40 +0800
> It's not much more modular than what we have in Emacs. The only real> difference is that it runs in a separate process, which I think also> poses freedom issues. AFAIK there is at least one proprietary frontend> for neovim.
I don't know if it is more or much more, but credit where credit is due.
This does help them receive more contributions than both Vim and Emacs.
Structuring the code with respect to software freedom is a whole different
subject, (which I support) but current ifdef toolkit jungle is not that.
> Details, please. We want to fix any bugs that crop up anywhere, and I> don't think we're missing out on any features.
I cannot see the future or what could've been, this is highly opinionated
but I do believe following latest C standard as early as possible is good
for an open source project.
xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
>> It's not much more modular than what we have in Emacs. The only real>> difference is that it runs in a separate process, which I think also>> poses freedom issues. AFAIK there is at least one proprietary frontend>> for neovim.> I don't know if it is more or much more, but credit where credit is due.
I don't see any reason why that credit due.
> This does help them receive more contributions than both Vim and Emacs.
How so?
> Structuring the code with respect to software freedom is a whole different> subject, (which I support) but current ifdef toolkit jungle is not that.
The "ifdef toolkit jungle" is restricted to the X-Windows code, and X is
so complicated to program for that every significant program using X
works that way.
> I cannot see the future or what could've been, this is highly opinionated> but I do believe following latest C standard as early as possible is good> for an open source project.
It's not possible in the first place.
Thanks.
Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01991.html
From: Po Lu
Date: Tue, 21 Dec 2021 19:05:43 +0800
>> This does help them receive more contributions than both Vim and Emacs.> How so?
I also wonder why, and this subject might need it's own thread. My first
guess is that their code is more approachable, whatever all that entails.
> The "ifdef toolkit jungle" is restricted to the X-Windows code, and X is> so complicated to program for that every significant program using X> works that way.
I plan to ask about this topic again when I am more knowledgeable, if that
is okay. Thanks for your insight.
> It's not possible in the first place.
Why not, assuming it is at some point considered to be beneficial
by maintainers?
xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> I also wonder why, and this subject might need it's own thread. My first> guess is that their code is more approachable, whatever all that entails.
I was asking for evidence that Neovim has more contributions than Emacs,
and that it will last.
> I plan to ask about this topic again when I am more knowledgeable, if that> is okay. Thanks for your insight.
Thanks. A word of advice is to not trust every article posted on an
internet blog or social media about the internals of Emacs. I find much
of that content to be plain misinformation.
> Why not, assuming it is at some point considered to be beneficial by> maintainers?
Right now it's not, I think. Even C11 would require dropping many
platforms that are currently supported, not to mention C17.
xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:
> I also wonder why, and this subject might need it's own thread. My first> guess is that their code is more approachable, whatever all that entails.
If there is a lack of contributors, I guess code quality can contribute
to that. But I'd strongly suspect that instead of looking for a fix at
the source code level, there are social and cultural reasons why many
find it hard to contribute to Emacs.
However, I don't really think it's correct to say that we have a lack of
contributors:
https://lars.ingebrigtsen.no/wp-content/uploads/2021/08/2021-08-13.png
What I observe instead is that we have many people who should be in a
position to contribute to Emacs core, but for one reason or another
choose not to. Instead, they develop third-party packages on MELPA (or,
more recently, NonGNU ELPA).
One thing we have discussed over and over is moving to sourcehut, but
AFAIK no one is working seriously on that. I really hope that someone
will take on that task soon. Maybe Lars or Eli would like to put it at
the top of etc/TODO (on the emacs-28 branch) on the off chance that it
helps.
>> One thing we have discussed over and over is moving to sourcehut, but> AFAIK no one is working seriously on that. I really hope that someone> will take on that task soon. Maybe Lars or Eli would like to put it at> the top of etc/TODO (on the emacs-28 branch) on the off chance that it> helps.
IIRC there are some issues with sourcehut still, like sending patches as
attachment, keeping us from migrating. I guess contributions to
sourcehut need to happen first. Maybe we should collect an exhausive
list of what features are needed before we can migrate? I don't
remember right now what else was missing.
Theo
Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01995.html
From: Stefan Kangas
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 04:05:32 -0800
> If there is a lack of contributors, I guess code quality can contribute> to that. But I'd strongly suspect that instead of looking for a fix at> the source code level, there are social and cultural reasons why many> find it hard to contribute to Emacs.
FWIW my impression is also that sociocultural reasons are a much more
significant reason on Emacs' case than code quality. Misinformation is
real. I simply imagine the latter something simpler to tackle.
Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01994.html
From: Po Lu
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 19:37:57 +0800
> I was asking for evidence that Neovim has more contributions than Emacs,
In total I suspect Emacs would win since it is much older. If we compare
recent and look at it's main repo and GUI projects it looks ahead.
We could collect github (which has built in statistics) and/or other
links and calculate but is it worth the effort?
> and that it will last.
It has been growing for a couple of years now, but who knows what will
happen...
> Thanks. A word of advice is to not trust every article posted on an> internet blog or social media about the internals of Emacs. I find much> of that content to be plain misinformation.
I intend have an article up called something like "Emacs: Facts and
Myths" and regularly link those then refute. It could even be a github
repo for everyone to add. I'm ok if someone beats me to it. :)
> Date: Tue, 21 Dec 2021 11:52:26 +0100 (CET)> Cc: Emacs Devel <emacs-devel@gnu.org>> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>> I do believe following latest C standard as early as possible is good> for an open source project.
Why is that? We are talking about a project most of whose codebase is
extremely stable and proven by many years of use. What could possibly
new compilers give us except destabilize the code (due to bugs in
early implementations of new standards)?