Re: Development Speed

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

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.

Re: Development Speed

[Po Lu]

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.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

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?

Re: Development Speed

[Po Lu]

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.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

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. :)

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> 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. :)

Please don't use GitHub!  While the situation is not as grave as it was
many years ago when GitHub was actively spreading disinformation about
free software licensing, it's still a service that essentially requires
users to run non-free JavaScript.

You can choose a better forge from this list:
https://www.gnu.org/software/repo-criteria-evaluation.en.html.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02084.html
From: Po Lu
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 08:56:49 +0800

> Please don't use GitHub! While the situation is not as grave as it was
> many years ago when GitHub was actively spreading disinformation about
> free software licensing, it's still a service that essentially requires
> users to run non-free JavaScript.

I mentioned that site precisely because the kind of people that needs
to see the article only dwell on there.  If they are self aware enough
to understand harm of non-free sites like GitHub, chances are they're not
very misinformed about Emacs. :)

Re: Development Speed

[Stefan Kangas]

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.

Re: Development Speed

[Theodor Thornhill]

>
> 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

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

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.

Re: Development Speed

[Eli Zaretskii]

> 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)?

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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 ...

As has been pointed out, we support lots of platforms, including old
platforms, and some of them don't have fresh new compilers.  If we
wanted to be quick to tell users "tough, your platform is no longer
supported," we could assume everyone has the latest GCC to use.
But those platforms are important.

Some of those old platforms are among the most important ones
because they allow operation without the Intel Management Engine
(or AMD's counterpart to that).

Our principles say we must do our best to encourage people to use a
free compiler if that is at all possible.  If the only C17 compiler
for a platform is nonfree, we must support using GCC instead.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > 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 ...
>
> As has been pointed out, we support lots of platforms, including old
> platforms, and some of them don't have fresh new compilers.  If we
> wanted to be quick to tell users "tough, your platform is no longer
> supported," we could assume everyone has the latest GCC to use.

This is not about having the latest GCC, this is about having a GCC
that's less than 10 years old.

> But those platforms are important.
>
> Some of those old platforms are among the most important ones
> because they allow operation without the Intel Management Engine
> (or AMD's counterpart to that).

Aren't there modern machines without this? Machines that are much more
performant, reliable and secure than those old ones, which usually are
tied to an unsupported OS full of security defects?

I sincerely don't get the stance of clinging to decades-old software and
hardware but when it comes to Emacs it must be the latest and shiniest.
As if emacs version N would cease to work the very moment emacs version
N+1 is released.

Have we checked lately if those machines that we purport to support are
able to run anything more complex than `emacs -Q'?

> Our principles say we must do our best to encourage people to use a
> free compiler if that is at all possible.  If the only C17 compiler
> for a platform is nonfree, we must support using GCC instead.

Nobody suggested using anything else than GCC.

I'm having the feeling that a good chunk of participants on this ml are
unwittingly but firmly commited to confine Emacs to the same
retro-computing world they live in.

The amount of tension and obstructionism that emerges every time that
someone suggests implementing some technology less than 20 years old is
overwhelming.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> This is not about having the latest GCC, this is about having a GCC
> that's less than 10 years old.

Simple example: GCC 3.4.x does not support C17, and it's recommended for
building the MS-DOS port, which doesn't only run on MS-DOS, but also
builds and runs on its free and actively developed replacement FreeDOS,
and also MS-Windows.

> Aren't there modern machines without this? Machines that are much more
> performant, reliable and secure than those old ones, which usually are
> tied to an unsupported OS full of security defects?

There are no others that are easy to obtain.  We don't want to just make
it possible for people to use Emacs with free software, but we also want
to make it easy.

> I sincerely don't get the stance of clinging to decades-old software and
> hardware but when it comes to Emacs it must be the latest and shiniest.

Why is that?

> As if emacs version N would cease to work the very moment emacs version
> N+1 is released.

Indeed, aside from Tramp and a few other packages, code remaining
compatible with older versions of Emacs is a rarity nowadays.

> Have we checked lately if those machines that we purport to support are
> able to run anything more complex than `emacs -Q'?

Yes.  For example, I tried quite a few things with the MS-DOS port, and
thanks to that, it works on Emacs 28 now.

The same situation exists with Windows 9x.  At work, we have a 9x system
for running legacy applications, and having Emacs 27 installed on that
system is really convenient.  And yes, that Emacs installation is
regularly used.

> The amount of tension and obstructionism that emerges every time that
> someone suggests implementing some technology less than 20 years old is
> overwhelming.

We already use the features of C11 and C17 where they are available.
That doesn't mean we have to go out of our way to break the build on
C99, which is regularly tested.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

>> Have we checked lately if those machines that we purport to support are
>> able to run anything more complex than `emacs -Q'?
>
> Yes.  For example, I tried quite a few things with the MS-DOS port, and
> thanks to that, it works on Emacs 28 now.
>
> The same situation exists with Windows 9x.  At work, we have a 9x system
> for running legacy applications, and having Emacs 27 installed on that
> system is really convenient.  And yes, that Emacs installation is
> regularly used.

How much RAM that machine has? Do you think it is justified to keep
Windows-9X support on Emacs for just a few anecdotal uses? If your
answer is that the extra work it adds is negligible and that you will
keep the maintenance burden, don't you think that keeping a separate
branch for Windows-9X (or any retro-computing platform, for that matter)
would be more adequate, instead of forcing everyone else to go over that
code when they read the sources?

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> How much RAM that machine has?

That machine is a Pentium 4 with 768 MB of RAM.  It is perfectly suited
to running Emacs with some customizations written for it to fill out
forms that need to be printed.

> Do you think it is justified to keep Windows-9X support on Emacs for
> just a few anecdotal uses?

Yes I do, because there is no reason to break it.

> If your answer is that the extra work it adds is negligible and that
> you will keep the maintenance burden, don't you think that keeping a
> separate branch for Windows-9X (or any retro-computing platform, for
> that matter) would be more adequate, instead of forcing everyone else
> to go over that code when they read the sources?

Not many people have to go through that code when reading the sources.
grep for `is_windows_9x', and you will see that we only test for Windows
9x in a few places.  It's also not a "retro computing platform" when
people are relying on it for real work, as opposed to play.

Eli being the MS-Windows expert here, I think he can explain further.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 11:38:43 +0100
> 
> don't you think that keeping a separate branch for Windows-9X (or
> any retro-computing platform, for that matter) would be more
> adequate, instead of forcing everyone else to go over that code when
> they read the sources?

No, I don't.  The Windows 9X support is confined to a small number of
well-defined places.  Maintaining a VCS branch is a much larger
hurdle.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > How much RAM that machine has? Do you think it is justified to keep
  > Windows-9X support on Emacs for just a few anecdotal uses?

We do.  You are free to disagree, but you're not going to convince us
by raging.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > How much RAM that machine has? Do you think it is justified to keep
>   > Windows-9X support on Emacs for just a few anecdotal uses?
>
> We do.

So you insist on supporting an obsolete, bug-ridden, unsecure and
*proprietary* OS with Emacs users numbers that probably range on the
single digits because... why?

Do you think that the reasons about availability of cheap used machines
on underprivileged communities that were valid 20 years ago maybe need
an update?

> You are free to disagree,

You are so gracious, thank you.

> but you're not going to convince us by raging.

Here we go again, misrepresenting and insulting people who don't align
with your view.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> So you insist on supporting an obsolete, bug-ridden, unsecure and
> *proprietary* OS with Emacs users numbers that probably range on the
> single digits because... why?

I doubt I rank among the "single digits".

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So you insist on supporting an obsolete, bug-ridden, unsecure and
>> *proprietary* OS with Emacs users numbers that probably range on the
>> single digits because... why?
>
> I doubt I rank among the "single digits".

Well, you need 9 more to prove me wrong ;-)

Seriously, part of my point is that if keeping Windows-9X support on
Emacs is helping people to keep using that OS, GNU is doing them a
disservice, both on technical and moral principles.

Re: Development Speed

[Arthur Miller]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> So you insist on supporting an obsolete, bug-ridden, unsecure and
>> *proprietary* OS with Emacs users numbers that probably range on the
>> single digits because... why?
>
> I doubt I rank among the "single digits".
Unless  you have different personailites and they all count as different users?
:-)

Sorry, just a joke; but on serious side, what is a good use of Windows 9x
these days? Other than just testing Emacs builds of course. It was a bad OS when
it came out, I can hardly imagine it got better nowadays.

Anyway, I doubt there are many users of Windows 9x left, even with you counted,
but I don't think there is much in Emacs sources targeting specifically Windows
9x either. Is it?

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > So you insist on supporting an obsolete, bug-ridden, unsecure and
  > > *proprietary* OS with Emacs users numbers that probably range on the
  > > single digits because... why?

  > I doubt I rank among the "single digits".

I will refrain from suggesting that we respond with a single digit ;-}.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To clarify the situation, it is Eli who thinks Windows 9 is worth
spending his time on.

The GNU Project attaches no particular importance to supporting
Windows (whatever version), but he's welcome to support it if he wants
to.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Dmitry Gutov]

On 22.12.2021 13:22, Po Lu wrote:
> aside from Tramp and a few other packages, code remaining
> compatible with older versions of Emacs is a rarity nowadays.

Very untrue.

Almost all notable third-party packages keep compatibility with Emacs 25 
(released 5 years ago).

Some exceptions (like lsp-mode and eglot) require Emacs 26 (released 3.5 
years ago).

And a fair number of packages work with Emacs 24 and older still.

Re: Development Speed

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Very untrue.

At least that was my opinion gained from years of watching people trying
to stay with Emacs 23.4.

Re: Development Speed

[Dmitry Gutov]

On 23.12.2021 04:00, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> Very untrue.
> At least that was my opinion gained from years of watching people trying
> to stay with Emacs 23.4.

There is a vast distance between the last version and 23.4 (released a 
decade ago).

Re: Development Speed

[Po Lu]

Dmitry Gutov <dgutov@yandex.ru> writes:

> There is a vast distance between the last version and 23.4 (released a
> decade ago).

In another 9 years, Emacs 27.2 will have been "released a decade ago" as
well.

Re: Development Speed

[dick]

PL> In another 9 years, Emacs 27.2 will have been "released a decade
PL> ago" as well.

Are you okay?  You appear to be having a seizure preventing you from
grasping the notion of a moving window in time.

Re: Development Speed

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 21:18:10 -0500
> 
> PL> In another 9 years, Emacs 27.2 will have been "released a decade
> PL> ago" as well.
> 
> Are you okay?  You appear to be having a seizure preventing you from
> grasping the notion of a moving window in time.

Please stop these senseless ad-hominem attacks on people here.  You
are dangerously close to crossing the proverbial red line.  Whatever
you want to say, please say it without calling people names.

Re: Development Speed

[Dmitry Gutov]

On 23.12.2021 04:07, Po Lu wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> There is a vast distance between the last version and 23.4 (released a
>> decade ago).
> In another 9 years, Emacs 27.2 will have been "released a decade ago" as
> well.

We should really hope that even people who are forced to use use 
outdated/cheap hardware, will be using *different* cheap hardware in 9 
years' time.

Re: Development Speed

[Arthur Miller]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 23.12.2021 04:07, Po Lu wrote:
>> Dmitry Gutov<dgutov@yandex.ru>  writes:
>> 
>>> There is a vast distance between the last version and 23.4 (released a
>>> decade ago).
>> In another 9 years, Emacs 27.2 will have been "released a decade ago" as
>> well.
>
> We should really hope that even people who are forced to use use outdated/cheap
> hardware, will be using *different* cheap hardware in 9 years' time.

That hardware will probably be warned out and not avialable in next 10 years.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 11:09:09 +0100
> 
> The amount of tension and obstructionism that emerges every time that
> someone suggests implementing some technology less than 20 years old is
> overwhelming.

Generalizations are almost always risking losing accuracy, but this
one does that with a vengeance.  I think it's not only inaccurate
(when talking about Emacs development), but also simply unfair.  E.g.,
some of the recent developments in Emacs use technology that is much
newer than "20 years", and I challenge you to come up with examples
that could back up your generalization, or even come close.

Re: Development Speed

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Wed, 22 Dec 2021 11:09:09 +0100
>> 
>> The amount of tension and obstructionism that emerges every time that
>> someone suggests implementing some technology less than 20 years old is
>> overwhelming.
>
> Generalizations are almost always risking losing accuracy, but this
> one does that with a vengeance.  I think it's not only inaccurate
> (when talking about Emacs development), but also simply unfair.  E.g.,
> some of the recent developments in Emacs use technology that is much
> newer than "20 years", and I challenge you to come up with examples
> that could back up your generalization, or even come close.

Example: the painful road from CVS to a modern VC system (first bzr and
then Git when was clear that bzr was inadequate at several levels, as
some warned before it was adopted.) And then many contributors didn't
bother to adapt to the distributed workflow and keep using Git as if it
were CVS, which makes the VC history hard to follow and of diminished
value.

Another example: the mailing list used as a bug tracker. We went from no
tracker at all to a big hack that happens to accommodate the personal
preferences of a few contributors while making things harder for
everyone else. Basic things like subscribing to a bug are too advanced:
you either monitor the mailing list or out of touch.

Another example: the amount of old cruft and hacks that pervades the
source code, prominently the C part.

The motif port was re-enabled with the excuse of two users saying that
they use it (two users! which actually didn't actually said that they
use the port, just that they build it.)

A the same time someone suggested experimenting with a new approach to
display and he was shunned ("We tried with such a library, many eons
ago. It was named lwlib, and you can judge for yourself how successful
it is.") Right, because if it failed many eons ago, trying again is
doomed to fail for sure, as technologies in software change as often as
in medieval masonry; and what the OP was suggesting is not what lwlib
does, IIUC.

So we maintain old code because two people "complain" (they didn't) and
meet with... let's say skepticism, proposals that seem to require
significant changes on the source base but with a high impact on
improving Emacs' potential. Lots of features and fixes are made trying
to not change the "stable" code, that's why we end having functions over
1000 lines long sprinkled with #ifdefs, which not only make any
substantial change very difficult, but are a big red sign saying "here
be dragons."

Emacs' architecture favors plug-in components, in the form of Elisp
packages, external processes and C libraries exposed to Elisp. That's
what keeps Emacs somewhat competitive, often thanks to heroic efforts.
But working on certain key parts of the core is very hard, both
technically and socially. You are concerned about the lack of C
contributors, but I think your worries are not well focused: there are
still plenty of C hackers around, but do they see our C core as
something they would enjoy contributing to?

Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Alan Mackenzie]

Hello, Óscar.

On Wed, Dec 22, 2021 at 16:51:41 +0100, Óscar Fuentes wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Óscar Fuentes <ofv@wanadoo.es>
> >> Date: Wed, 22 Dec 2021 11:09:09 +0100

> >> The amount of tension and obstructionism that emerges every time that
> >> someone suggests implementing some technology less than 20 years old is
> >> overwhelming.

> > Generalizations are almost always risking losing accuracy, but this
> > one does that with a vengeance.  I think it's not only inaccurate
> > (when talking about Emacs development), but also simply unfair.  E.g.,
> > some of the recent developments in Emacs use technology that is much
> > newer than "20 years", and I challenge you to come up with examples
> > that could back up your generalization, or even come close.

Your last post comes over as one big moan.  You moan about perfectly
valid decisions, some of which didn't turn out optimally.  You moan about
perfectly valid decisions, full stop.  You or somebody else could have
moaned about the opposite decisions, had they been so taken, equally
well.

The main point of my post is that Eli is having to deal with a lot of
negative posting at the moment, and this is a Bad Thing.  He could do
with a break.

We're approaching what is in large swathes of the world the "season of
goodwill".  Why don't we reflect that in our posts to emacs-devel, in
particular to those directed at Eli?

I'm not going to respond to your points in detail; that would just lead
to more interminable arguments.  Suffice it to say that I disagree with
most of them as well as disliking the tone they were expressed in.

A happy Christmas to you!

> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Óscar Fuentes]

Alan Mackenzie <acm@muc.de> writes:

> Your last post comes over as one big moan.  You moan about perfectly
> valid decisions, some of which didn't turn out optimally.  You moan about
> perfectly valid decisions, full stop.

That's your opinion. It's understandable that you talk about "perfectly
valid decisions", since you were strongly vocal when those decisions
were made and had a significant impact on them. Which is fine.

> The main point of my post is that Eli is having to deal with a lot of
> negative posting at the moment,

I'm pretty sure that Eli:

1. knows how much I appreciate his work.

2. is quite capable of speaking for himself.

3. any observation on my messages is not addressed to him personally,
   but to the project as a whole, since a long time before he was the
   maintainer. BTW, I energetically lobbied for using bzr over git at
   the time and thought that debbugs were better than nothing. I was as
   wrong as the wrongest (non-)participant on those discussions.

> We're approaching what is in large swathes of the world the "season of
> goodwill".

I'll refrain from expressing my opinion about the concept of seasonal
goodwill.

Finally, I will say that you are not the only one who feels entitled to
moan and rant on emacs-devel :-)

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[dick]

AM> He could do with a break.

You make it sound as if he doesn't relish the convo.

Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
the usual suspects from this list take the bait.  And why wouldn't they?
It's much easier and more gratifying putting these unheralded
know-it-all's in their place, than writing code and fixing bugs.

I wonder if our maintainer wears a toga.  He's really nailed down the
Hippocratic Oath of "first, do no harm" (the corollary of which is
"don't move fast and don't break things"), and his Socratic approach to
answering questions by asking five more is masterful.

Re: Can we give Eli a break, please? [ Was: Re: Development Speed ]

[Eli Zaretskii]

> From: dick <dick.r.chiang@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 22 Dec 2021 12:12:39 -0500
> 
> Uninformed lookie-loos such as xenodasein do fly-by's all the time, and
> the usual suspects from this list take the bait.  And why wouldn't they?
> It's much easier and more gratifying putting these unheralded
> know-it-all's in their place, than writing code and fixing bugs.

I consider it part of my job to participate in discussions related to
Emacs development where I think I have something potentially useful to
say.

But thank you so much for you kind offer of managing my time and
tasks.

Re: Development Speed

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 22 Dec 2021 16:51:41 +0100
> 
> Example: the painful road from CVS to a modern VC system (first bzr and
> then Git when was clear that bzr was inadequate at several levels, as
> some warned before it was adopted.) And then many contributors didn't
> bother to adapt to the distributed workflow and keep using Git as if it
> were CVS, which makes the VC history hard to follow and of diminished
> value.

That's a lopsided view of what happened, with denigrating epithets
("painful", "inadequate") to season it.  The switch to bzr was no more
painful than any switch from a centralized VCS to a dVCS could be
expected to be.  At the time we switched, bzr was a viable
alternative, used by several other projects (some of which kept using
it long after we switched to Git).  And how the problem with
contributors' mindsets is any evidence in favor of your argument is a
mystery to me.

> Another example: the mailing list used as a bug tracker. We went from no
> tracker at all to a big hack that happens to accommodate the personal
> preferences of a few contributors while making things harder for
> everyone else. Basic things like subscribing to a bug are too advanced:
> you either monitor the mailing list or out of touch.

Another lopsided view: we are looking for a better system for quite
some time, and until now none was found to satisfy our basic
requirements.  Hopefully, sourcehut will.

For a more balanced view, try to find a project that is happy with its
bug tracker.  I'm still looking.

> Another example: the amount of old cruft and hacks that pervades the
> source code, prominently the C part.

Really?  Like what?

And how is this a "technology" problem?  Or would you like us to
rewrite Emacs in Rust?

Come on, get real!  This is supposed to be a serious discussion, not a
mud-throwing match.

> The motif port was re-enabled with the excuse of two users saying that
> they use it (two users! which actually didn't actually said that they
> use the port, just that they build it.)

And how is this any evidence that we procrastinate in our acceptance
of new technology?  Does Motif support disallow any such advances?

> A the same time someone suggested experimenting with a new approach to
> display and he was shunned ("We tried with such a library, many eons
> ago. It was named lwlib, and you can judge for yourself how successful
> it is.") Right, because if it failed many eons ago, trying again is
> doomed to fail for sure, as technologies in software change as often as
> in medieval masonry; and what the OP was suggesting is not what lwlib
> does, IIUC.

Maybe you misunderstood what the OP was suggesting.  Or maybe you have
some different suggestion in mind, because what he was suggesting
makes no sense to me.  Do we have to accept any suggestion whatsoever,
no matter if it does or doesn't make sense, lest Óscar will accuse us
of being backward?

> So we maintain old code because two people "complain" (they didn't) and
> meet with... let's say skepticism, proposals that seem to require
> significant changes on the source base but with a high impact on
> improving Emacs' potential. Lots of features and fixes are made trying
> to not change the "stable" code, that's why we end having functions over
> 1000 lines long sprinkled with #ifdefs, which not only make any
> substantial change very difficult, but are a big red sign saying "here
> be dragons."

No, we maintain old code because it works and because we decide not to
break it.  It's a decision which has reasons, you just choose to
ignore them because you want to make a point in an argument.

And how is this any evidence of (not) accepting new technologies,
anyway?  Or are we changing the subject now to something like "all I
hated in Emacs development but was afraid to say out loud"?

> Emacs' architecture favors plug-in components, in the form of Elisp
> packages, external processes and C libraries exposed to Elisp. That's
> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
> But working on certain key parts of the core is very hard, both
> technically and socially. You are concerned about the lack of C
> contributors, but I think your worries are not well focused: there are
> still plenty of C hackers around, but do they see our C core as
> something they would enjoy contributing to?

That is against any reasonable experience and facts on so many levels
that I don't know where to start.  Here's several items, as food for
thought:

  . Emacs extensibility via Lisp can only go so far, sooner or later
    it hits a wall.  Some extensions and major developments need
    changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in
    with Lisp is bound to fail.  Evidence: linum vs native line
    numbers.  Evidence: bidirectional editing (which originally had a
    Lisp implementation which went nowhere).  Evidence: HarfBuzz vs
    "ligatures" via prettify-symbols-mode.
  . Working on the C level requires certain efforts, but is far from
    being impossible for novices.  Evidence: face-extension feature
    and display-fill-column-indicator-mode feature that was coded by
    someone who started from almost zero knowledge of the display
    code.  Evidence: several people who started working on the C code
    just recently (see Git logs).
  . Reasons why "plenty of C hackers", if they indeed exist (and IME
    the jury is still out on that one), need serious investigation.
    I have my guesses about that, but they will remain unsaid at this
    point.

Bottom line: I find that Emacs recently picks up quite a few new
technologies, and for an old and stable program such as Emacs we
should be proud of what we accomplished.

Re: Development Speed

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

I'm skipping over several things to keep this short and to the point.

>> A the same time someone suggested experimenting with a new approach to
>> display and he was shunned ("We tried with such a library, many eons
>> ago. It was named lwlib, and you can judge for yourself how successful
>> it is.") Right, because if it failed many eons ago, trying again is
>> doomed to fail for sure, as technologies in software change as often as
>> in medieval masonry; and what the OP was suggesting is not what lwlib
>> does, IIUC.
>
> Maybe you misunderstood what the OP was suggesting.

I don't think so, the few doubts I had vanished after reading his recent
messages.

> Or maybe you have
> some different suggestion in mind, because what he was suggesting
> makes no sense to me.

Maybe asking for clarification? I can expand on the proposal, but
somebody else already did. I can answer specifics about that topic if
necessary.

> Do we have to accept any suggestion whatsoever,
> no matter if it does or doesn't make sense, lest Óscar will accuse us
> of being backward?

Well, that's a glaring example of what I said about not internalizing
the social implications of our "new" tools :-) If you have doubts about
his suggestion, you could just say "I don't get what you are proposing
but if you think it is good for Emacs then sure, go ahead and I'll
examine your work when you have something to show." Then the OP goes to
work on his personal repo. That has almost zero cost to you, both on
effort and risk. It's not like the old times when you had to give write
permissions to the project's repo and destabilizing WIP usually happened
on the main branch because merges on CVS are a pain.

>> Emacs' architecture favors plug-in components, in the form of Elisp
>> packages, external processes and C libraries exposed to Elisp. That's
>> what keeps Emacs somewhat competitive, often thanks to heroic efforts.
>> But working on certain key parts of the core is very hard, both
>> technically and socially. You are concerned about the lack of C
>> contributors, but I think your worries are not well focused: there are
>> still plenty of C hackers around, but do they see our C core as
>> something they would enjoy contributing to?
>
> That is against any reasonable experience and facts on so many levels
> that I don't know where to start.  Here's several items, as food for
> thought:
>
>   . Emacs extensibility via Lisp can only go so far, sooner or later
>     it hits a wall.  Some extensions and major developments need
>     changes in C, and any attempt to kludge^H^H^H^H^H^Hplug them in
>     with Lisp is bound to fail.  Evidence: linum vs native line
>     numbers.  Evidence: bidirectional editing (which originally had a
>     Lisp implementation which went nowhere).  Evidence: HarfBuzz vs
>     "ligatures" via prettify-symbols-mode.

Very true, but I don't see how this contradicts what I wrote. The
occasional new feature on core base happens, but extensions (Elisp,
interfaces to external processes and, more recently, modules) makes the
bulk of Emacs' user-perceptible improvements, much more so if we count
external packages.

>   . Working on the C level requires certain efforts, but is far from
>     being impossible for novices.  Evidence: face-extension feature
>     and display-fill-column-indicator-mode feature that was coded by
>     someone who started from almost zero knowledge of the display
>     code.  Evidence: several people who started working on the C code
>     just recently (see Git logs).

I'm convinced that there is a strong survival bias at play here.

> Bottom line: I find that Emacs recently picks up quite a few new
> technologies, and for an old and stable program such as Emacs we
> should be proud of what we accomplished.

This definitely agree with.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Some of those old platforms are among the most important ones
  > > because they allow operation without the Intel Management Engine
  > > (or AMD's counterpart to that).

  > Aren't there modern machines without this? Machines that are much more
  > performant, reliable and secure than those old ones, which usually are
  > tied to an unsupported OS full of security defects?

Not that I've heard of.  Every so often I check whether there has been
progress.

  > Have we checked lately if those machines that we purport to support are
  > able to run anything more complex than `emacs -Q'?

I check this all day, every day.

  > > Our principles say we must do our best to encourage people to use a
  > > free compiler if that is at all possible.  If the only C17 compiler
  > > for a platform is nonfree, we must support using GCC instead.

  > Nobody suggested using anything else than GCC.

Your general demand would, under some circumstances, imply that.

  > I'm having the feeling that a good chunk of participants on this ml are
  > unwittingly but firmly commited to confine Emacs to the same
  > retro-computing world they live in.

Your verbal aggression is very unkind, and makes discussing with you
unpleasant.  We don't need your approval or agreement, so the aggression
won't win you anything.

Please try to follow the GNU Kind Communication Guidelines,
https://gnu.org/philosophy/kind-communication.html.  Cooperating,
to whatever extent we have goals in common, will be much easier
if you do that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Óscar Fuentes]

Richard Stallman <rms@gnu.org> writes:

>   > > Some of those old platforms are among the most important ones
>   > > because they allow operation without the Intel Management Engine
>   > > (or AMD's counterpart to that).
>
>   > Aren't there modern machines without this? Machines that are much more
>   > performant, reliable and secure than those old ones, which usually are
>   > tied to an unsupported OS full of security defects?
>
> Not that I've heard of.  Every so often I check whether there has been
> progress.

AFAIK there are multiple machines that offer more computing power (on
terms of CPU, RAM, storage, etc) than the typical medium-range PC from
15 years ago. AFAIK a humble Raspberry Pi fits that description and it
has a fraction of the propietary firmware most of those old PCs have.

Then we have some vendors that specialize on providing PCs with as few
binary blobs as possible, with IME and its equivalents disabled.

I agree that it is difficult to acquire a new computer which is
completely Free, but it is fairly easy to get a new computer which
contains far less proprietary elements than the typical PC sold before
IME became a thing.

>   > > Our principles say we must do our best to encourage people to use a
>   > > free compiler if that is at all possible.  If the only C17 compiler
>   > > for a platform is nonfree, we must support using GCC instead.
>
>   > Nobody suggested using anything else than GCC.
>
> Your general demand would, under some circumstances, imply that.

I can't imagine those circunstances, since Gcc is the most ubiquitous
compiler out there.

>   > I'm having the feeling that a good chunk of participants on this ml are
>   > unwittingly but firmly commited to confine Emacs to the same
>   > retro-computing world they live in.
>
> Your verbal aggression is very unkind,

What you call verbal aggression I call speaking own's mind. It is not
like as if I throwed that paragraph out of the blue, there is a lot of
context.

> and makes discussing with you unpleasant.
>
> We don't need your approval or agreement, so the aggression
> won't win you anything.
>
> Please try to follow the GNU Kind Communication Guidelines,
> https://gnu.org/philosophy/kind-communication.html.  Cooperating,
> to whatever extent we have goals in common, will be much easier
> if you do that.

The very first guideline is:

   Please assume other participants are posting in good faith, even if
   you disagree with what they say.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

> AFAIK there are multiple machines that offer more computing power (on
> terms of CPU, RAM, storage, etc) than the typical medium-range PC from
> 15 years ago. AFAIK a humble Raspberry Pi fits that description and it
> has a fraction of the propietary firmware most of those old PCs have.

Raspberry Pis cannot run usably with 100% free firmware, while the old
PCs RMS was referring to can.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> AFAIK there are multiple machines that offer more computing power (on
>> terms of CPU, RAM, storage, etc) than the typical medium-range PC from
>> 15 years ago. AFAIK a humble Raspberry Pi fits that description and it
>> has a fraction of the propietary firmware most of those old PCs have.
>
> Raspberry Pis cannot run usably with 100% free firmware, while the old
> PCs RMS was referring to can.

Are you implying that it is possible to turn regular PCs from before IME
into systems with 100% free firmware?

There are multiple components on a typical system that use their own
firmware, many of them are not writable.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Raspberry Pis cannot run usably with 100% free firmware, while the old
>> PCs RMS was referring to can.

> Are you implying that it is possible to turn regular PCs from before IME
> into systems with 100% free firmware?

Yes.  In fact, some small businesses buy those PCs and install the free
software and firmware onto them.

> There are multiple components on a typical system that use their own
> firmware, many of them are not writable.

If they are not writeable, they are not free or nonfree, for the same
reason hardware is not free or nonfree.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> Raspberry Pis cannot run usably with 100% free firmware, while the old
>>> PCs RMS was referring to can.
>
>> Are you implying that it is possible to turn regular PCs from before IME
>> into systems with 100% free firmware?
>
> Yes.  In fact, some small businesses buy those PCs and install the free
> software and firmware onto them.

Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.

>> There are multiple components on a typical system that use their own
>> firmware, many of them are not writable.
>
> If they are not writeable, they are not free or nonfree, for the same
> reason hardware is not free or nonfree.

Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
being proprietary? I don't think so.

Re: Development Speed

[Po Lu]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> Yes.  In fact, some small businesses buy those PCs and install the free
>> software and firmware onto them.

> Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.

Indeed it doesn't, but the devices Richard referred to are 100% free
with the free firmware and software installed.

> Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
> being proprietary?

Yes.  The ME is undesirable for other reasons, but if the firmware and
ME were read-only they would not pose freedom issues, as they would be
indistinguishable from hardware.

Re: Development Speed

[Óscar Fuentes]

Po Lu <luangruo@yahoo.com> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>>> Yes.  In fact, some small businesses buy those PCs and install the free
>>> software and firmware onto them.
>
>> Installing GNU/Linux and a Free BIOS does not make a machine 100% Free.
>
> Indeed it doesn't, but the devices Richard referred to are 100% free
> with the free firmware and software installed.

And those are off-the-shelf x86(_64) PCs? Or are machines with special
hardware?

>> Then if the BIOS/UEFI/IME were read-only the FSF would be fine with them
>> being proprietary?
>
> Yes.  The ME is undesirable for other reasons, but if the firmware and
> ME were read-only they would not pose freedom issues, as they would be
> indistinguishable from hardware.

Then I'm more of a Free Software purist than the FSF.

I'm interested on what rms says about this.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Raspberry Pis cannot run usably with 100% free firmware, while the old
  > PCs RMS was referring to can.

For more details, see fsf.org/resources/hw/single-board-computers.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The very first guideline is:

  >    Please assume other participants are posting in good faith, even if
  >    you disagree with what they say.

That's right.  And I'm glad to say that I did not impute bad faith to
your words.  What I said is that you were raging, speaking with
aggression, and that that is unkind.

  > > Your verbal aggression is very unkind,
  ...  
  > > and makes discussing with you unpleasant.

  > > We don't need your approval or agreement, so the aggression
  > > won't win you anything.

  > > Please try to follow the GNU Kind Communication Guidelines,
  > > https://gnu.org/philosophy/kind-communication.html.  Cooperating,
  > > to whatever extent we have goals in common, will be much easier
  > > if you do that.

Following these guidelines is not always easy.  Even while making an effort,
one can fail to do it well.  Talking with someone that engages in verbal
aggression is stressful, and stress makes one more likely to make mistakes
oneself.

That's part of the reason it is important for you to make an effort 
to stop your aggression.

  > What you call verbal aggression I call speaking own's mind. It is not
  > like as if I throwed that paragraph out of the blue, there is a lot of
  > context.

What matters to this discussion is that it's verbal aggression and it
causes stress for the rest of us.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Arthur Miller]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Some of those old platforms are among the most important ones
>   > > because they allow operation without the Intel Management Engine
>   > > (or AMD's counterpart to that).
>
>   > Aren't there modern machines without this? Machines that are much more
>   > performant, reliable and secure than those old ones, which usually are
>   > tied to an unsupported OS full of security defects?
>
> Not that I've heard of.  Every so often I check whether there has been
> progress.

There are not, and there probably will not be. I think it is a decision
enforced by the goverment of a certain world power. Maybe if you used CPUs
produced in some other country for some other market, but do you really trust a
hardware produced in maybe even less free country where everything is under
control of one party? Getting rid of such features in modern hardware can be
only done in political way, but the wide masses are not aware of the problems of
mass surviliance so political solution is probably not possible at this time. As
of current using old CPUs without such hardware is the only solution, but that
is not a sustainable solution. Eventually the world will run out of old CPUs,
and the majority of population already can not obtain one such CPU.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I was talking about the need for nonfree software in the software load
to make the computer work.

You've changed to a different issue: whether the hardware itself
is malicious.

There IS known malicious hardware in our computers.  The Management
Engine (and its AMD counterpart).  HDCP.  TPM.  Other DRM hardware.
Malicious hardware is as bad as malicious software -- it's the
same issue.

But hardware and software are different issues in other respects.

See https://gnu.org/philosophy/free-hardware-designs.html for the GNU
Project stand on hardware.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02094.html
From: Richard Stallman
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 23:16:24 -0500

I just noticed that I used the term open source there and not free
software; a bad habit I am getting over. :)

> Some of those old platforms are among the most important ones
> because they allow operation without the Intel Management Engine
> (or AMD's counterpart to that).

This a very critical point I forgot to consider, good to bring it up.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02123.html
From: Óscar Fuentes
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 11:09:09 +0100

>> ... without the Intel Management Engine
>> (or AMD's counterpart to that).
> Aren't there modern machines without this? Machines that are much more
> performant, reliable and secure than those old ones, which usually are
> tied to an unsupported OS full of security defects?

Are there recent, powerful amd64 cores without built-in surveillance out
there?  Accessibility outside of first-world is also important, I'd be
interested to know those if you care to help.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02012.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 16:39:40 +0200

> ... I'm amazed that you think this is a disadvantage in Emacs.

But it doesn't work, it returns nil!  Shouldn't it just throw error
when called in TUI or just get not bound to it's symbol?

> This is a feature: Lisp programs almost never need to know whether
> they run on text-mode or GUI displays.  If a Lisp program had to ask
> on every step whether the display is TTY or GUI...

I think they have to, unless TUI and GUI capabilites of a program are
exactly the same, which would be unfortunate.  For example this package
https://github.com/tumashu/ivy-posframe only works on and is meaningful
for GUI. But:

> ... we deliberately implemented most of the GUI features on TTYs:
> multiple frames, colors (with transparent translation of X colors),
> mouse support, menus and dialogs -- in order to eliminate most of the
> differences on the Lisp level.

Shouldn't there exist a set of functions that exit for GUI, a set that
exist for TUI, and as their intersection a set of interface-agnostic
functions?  Things you mentioned mostly live in the intersection
anyway.

> ... One of the worst "surprises" when
> building a new version of a package is to find out it no longer
> supports your compiler/linker/libraries...

If a system has internet connection and is able to run the latest Emacs,
shouldn't it be able to get a reasonably recent GCC?  Asking for my own
education, feel free to pass...



> We are not talking about platforms, we are talking about GNU/Linux
> systems that still use old GCC versions.  There are quite a lot of
> those...

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02014.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 16:48:47 +0200

> 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)?

I don't know how bad the situation is but I feel like I mentioned C++20
and not C11? GCC is the backbone of GNU and C11 was implemented in it
like 10 years ago IIRC. Compiling Emacs 29 (assuming it is C11, which I
don't think it will or should) on a system system without C11 sounds,
rather unusual?  There is always 28.  I am certainly not an authority on this
subject, maybe there exists something like the "Steam Hardware Survey" but
for GNU/GCC?

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Shouldn't there exist a set of functions that exit for GUI, a set that
> exist for TUI, and as their intersection a set of interface-agnostic
> functions?  Things you mentioned mostly live in the intersection
> anyway.

Those functions generally start with `x-', and the names of the various
window systems for the features specific to them.

> If a system has internet connection and is able to run the latest Emacs,
> shouldn't it be able to get a reasonably recent GCC?  Asking for my own
> education, feel free to pass...

No.  Building a new version of GCC on a system designed for an older one
is a recipe for disaster.

> I don't know how bad the situation is but I feel like I mentioned C++20
> and not C11? GCC is the backbone of GNU and C11 was implemented in it
> like 10 years ago IIRC. Compiling Emacs 29 (assuming it is C11, which I
> don't think it will or should) on a system system without C11 sounds,
> rather unusual?

10 years is awfully early, don't you think?  IIRC, Eli uses a computer
running Windows XP, which is 20 years old.

We supported K&R until (I think) 2007, when it became clear that Emacs
wasn't actually going to build with a K&R compiler or the machines that
still had K&R compilers.

Re: Development Speed

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 01:52:53 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> But it doesn't work, it returns nil!  Shouldn't it just throw error
> when called in TUI or just get not bound to it's symbol?

If you show the code that you tried (preferably starting from "emacs -Q"),
I could try making up my mind whether there's a problem here in how
Emacs behaves.  Signaling an error is not necessarily TRT.

> > This is a feature: Lisp programs almost never need to know whether
> > they run on text-mode or GUI displays.  If a Lisp program had to ask
> > on every step whether the display is TTY or GUI...
> 
> I think they have to

No, they don't.

> unless TUI and GUI capabilites of a program are
> exactly the same, which would be unfortunate.

They don't even if the behavior is the same (why is that unfortunate?)
or if it is not the same (assuming the differences are either
self-evident or documented).

> For example this package https://github.com/tumashu/ivy-posframe
> only works on and is meaningful for GUI.

Maybe you should report a bug to the developers of that package,
then.  The Emacs development philosophy is what I described

> But:
> 
> > ... we deliberately implemented most of the GUI features on TTYs:
> > multiple frames, colors (with transparent translation of X colors),
> > mouse support, menus and dialogs -- in order to eliminate most of the
> > differences on the Lisp level.
> 
> Shouldn't there exist a set of functions that exit for GUI, a set that
> exist for TUI, and as their intersection a set of interface-agnostic
> functions?

No, there should be (ideally) only one set.  Applications should be
free from dealing with this distinction as much as possible.

> > ... One of the worst "surprises" when
> > building a new version of a package is to find out it no longer
> > supports your compiler/linker/libraries...
> 
> If a system has internet connection and is able to run the latest Emacs,
> shouldn't it be able to get a reasonably recent GCC?  Asking for my own
> education, feel free to pass...

The problem is, once you download the latest GCC, it turns out it also
needs a later Binutils, and a later GMP; and the latest Binutils need
a later glibc and half a dozen of other libraries and tools upgraded,
etc. etc.  before long you find yourself installing dozens of new
packages.  At which point it turns out that your hardware is too old
and cannot support some of them.

If you have never been in such a situation, you may not realize how
maddening it could be, or may not believe me it happens.  But it is
actually very real.

> > 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)?
> 
> I don't know how bad the situation is but I feel like I mentioned C++20
> and not C11? GCC is the backbone of GNU and C11 was implemented in it
> like 10 years ago IIRC. Compiling Emacs 29 (assuming it is C11, which I
> don't think it will or should) on a system system without C11 sounds,
> rather unusual?  There is always 28.  I am certainly not an authority on this
> subject, maybe there exists something like the "Steam Hardware Survey" but
> for GNU/GCC?

You are not listening.  I asked you what would be the advantages, and
you answer a very different question.

In any case, we already probe the compiler for support of C11, and if
it does, activate that while compiling.  That's not the issue being
discussed here.  The issue being discussed is whether we should
actively reject compilers that don't support older C standards.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02139.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 14:41:18 +0200

> You are not listening. I asked you what would be the advantages, and
> you answer a very different question.

Ah, OK.  In my case I find it harder to work on older C bases, as
I don't have experience in legacy development.  I am very familiar with
ISO/IEC 9899:2018, but when I see ANSI C it is very stressing not
being certain whether I am looking at some UB, or legacy compiler bug.
Likely there are many other new generation developers like me who
stumble upon this while looking to contribute to huge free software
projects.



> In any case, we already probe the compiler for support of C11, and if
> it does, activate that while compiling. That's not the issue being
> discussed here. The issue being discussed is whether we should
> actively reject compilers that don't support older C standards.

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02123.html
From: Óscar Fuentes
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 11:09:09 +0100

> I sincerely don't get the stance of clinging to decades-old software and
> hardware but when it comes to Emacs it must be the latest and shiniest.
> As if Emacs version N would cease to work the very moment Emacs version
> N+1 is released.

Why is it not viable to update the code base and compiler as major
versions progress?  Couldn't we back-port much desired new features as
packages/modules?  It isn't like older Emacs versions are useless,
they are all extremely useful and unrivaled.

Re: Development Speed

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 16:15:04 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, Ofv <ofv@wanadoo.es>
> 
> Ah, OK.  In my case I find it harder to work on older C bases, as
> I don't have experience in legacy development.  I am very familiar with
> ISO/IEC 9899:2018, but when I see ANSI C it is very stressing not
> being certain whether I am looking at some UB, or legacy compiler bug.
> Likely there are many other new generation developers like me who
> stumble upon this while looking to contribute to huge free software
> projects.

I don't think I understand what you are getting at.  The issue you
raised was why we don't use C11, so my question to you is what is it
in C11 that is not in C99 that you would miss in a program like Emacs?

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02200.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 18:37:50 +0200

> I don't think I understand what you are getting at.  The issue you
> raised was why we don't use C11, so my question to you is what is it
> in C11 that is not in C99 that you would miss in a program like Emacs?

C99 of course cause much less stress than ANSI. (Unless one knows the
difference of pitfalls between C99 and C11 standards then it is smooth
sailing.)

Isn't a new compiler compiling old standard more likely to cause
non-compliant behavior, than the one it is developed for? (Assuming
implementation has achieved maturity.)

Then there is VLAs, won't using C99 result in the worse optimization?

We would need to know how many UB related bugs are hiding in
entirety of Emacs for me to make any real case anyway.

Maybe the historical and current reasoning regarding to the choice of
"-std=" with their pro/contra exist in a series of comments, or somewhere
else, then I (or any other n00b) can refer that instead of bothering you
with these.  Thanks for indulging my curiosity so far.

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Isn't a new compiler compiling old standard more likely to cause
> non-compliant behavior, than the one it is developed for? (Assuming
> implementation has achieved maturity.)

No.  If that happens in GCC, then it is a bug.

> Then there is VLAs, won't using C99 result in the worse optimization?

No, and I think we prefer alloca to VLAs (please correct me if this is
not the case though.)

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Dec 23, 2021, 16:42 by luangruo@yahoo.com:

> No.  If that happens in GCC, then it is a bug.
>
Yes, that's the point.  It is a lot more likely to happen as
the focus is on new standard.

Re: Development Speed

[Stefan Monnier]

xenodasein--- via "Emacs development discussions." [2021-12-23 14:48:32] wrote:
> Dec 23, 2021, 16:42 by luangruo@yahoo.com:
>> No.  If that happens in GCC, then it is a bug.
> Yes, that's the point.  It is a lot more likely to happen as
> the focus is on new standard.

That's not my experience.  It's rather than other way around: features
of the new standard are more likely to have bugs because they've not
been tested for as many years.


        Stefan

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02400.html
From: Stefan Monnier

> That's not my experience.  It's rather than other way around: features
> of the new standard are more likely to have bugs because they've not
> been tested for as many years.

I would say the same, if we were talking about C2X, but would you also
say the same for C11, which is ten years old? (Well, I originally said
C17 but on paper they are the same bar a some of fixes.)

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I would say the same, if we were talking about C2X, but would you also
> say the same for C11, which is ten years old? (Well, I originally said
> C17 but on paper they are the same bar a some of fixes.)

That's the case for C11 as well.  I'd say gnu99 and gnu89 are the most
well-tested dialects, IME.

Re: Development Speed

[Tim Cross]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> xenodasein--- via "Emacs development discussions." [2021-12-23 14:48:32] wrote:
>> Dec 23, 2021, 16:42 by luangruo@yahoo.com:
>>> No.  If that happens in GCC, then it is a bug.
>> Yes, that's the point.  It is a lot more likely to happen as
>> the focus is on new standard.
>
> That's not my experience.  It's rather than other way around: features
> of the new standard are more likely to have bugs because they've not
> been tested for as many years.
>

Yes, that would mirror my experience as well.

There is also the issue that new standards don't always mean better -
only newer. The software industry is littered with examples where a new
standard has turned out to be a step backwards rather than forward. 

Re: Development Speed

[Stefan Monnier]

> Then there is VLAs, won't using C99 result in the worse optimization?

Compiler optimizations have very little impact on Emacs-style code
anyway.

> We would need to know how many UB related bugs are hiding in
> entirety of Emacs for me to make any real case anyway.

According to any of the C standards, Emacs is just one large
undefined behavior.

> Maybe the historical and current reasoning regarding to the choice of
> "-std=" with their pro/contra exist in a series of comments, or somewhere
> else, then I (or any other n00b) can refer that instead of bothering you
> with these.  Thanks for indulging my curiosity so far.

AFAIK this is only used to try and get better warnings.

We don't care what feature belongs to which standard.  So if you want to
suggest changes, either send a concrete patch or discuss
concrete/detailed language features you think we should be using (or
should stop using), with a mention of which versions of which compilers
support them.


        Stefan

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02399.html
From: Stefan Monnier

> > Then there is VLAs, won't using C99 result in the worse optimization?
> Compiler optimizations have very little impact on Emacs-style code
> anyway.

I would still add that to the list of pros, albeit with a small weight.

> According to any of the C standards, Emacs is just one large
> undefined behavior.

Discussion of C stemmed from making the code-base easier to work on,
especially for people who are not seasoned legacy experts.

> We don't care what feature belongs to which standard.  So if you want to
> suggest changes, either send a concrete patch or discuss
> concrete/detailed language features you think we should be using (or
> should stop using)...

In the same vein, my thought at least, it was more about making the code
more standard compliant, predictable, rather than specific features.

> ... with a mention of which versions of which compilers
> support them.

I don't how to reason about this without having the big picture.
And to have that I asked for existence of relevant documentation
in a recent mail.  Reading the whole build system, as with reading
majority of all C code is not it.  It is only something someone
who's spent years on maintaining Emacs can know.  And there are
some things not written at all, for example RMS in this subject
mentioned a significant issue on some old hardware support.

I can't see how this is something to ask over small patches, as
in a patch that says "Make these few lines of code C17 compliant"
wouldn't mean much without a plan.

Re: Development Speed

[Stefan Monnier]

> In the same vein, my thought at least, it was more about making the code
> more standard compliant, predictable, rather than specific features.

I'd be surprised if the compliance (or not) of Emacs's C code with
specific versions of the C standard would make any difference to
a newcomer.

The difficulty in our C code comes from various aspects, none of which
have much to do with the C language itself:
- The use of macros to wrap accesses/definitions of Lisp data/functions.
  REmacs had a slightly better story there, but still with the same "this
  is not your vanilla Rust code" problem.
- The actual logic of the code.
- The cruft accumulated over the years.
- The impact of the (conservative) GC which implies that things aren't
  always what they appear to be (e.g. when our string compaction moves
  string data under the feet of unsuspecting C code).

Over the years, we've managed to reduce the use of macros (replaced by
inlinable functions) to some extent, partly thanks to improvement in
compilers, but it didn't change much to the code overall.

> I can't see how this is something to ask over small patches, as
> in a patch that says "Make these few lines of code C17 compliant"
> wouldn't mean much without a plan.

If you describe a concrete problem linked to being "not C17 compliant",
then maybe we can start thinking about a plan.  But so far all I've seen
is "compliance for its own sake".

I don't even know of any single place where we're not "C17 compliant".


        Stefan

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02433.html
From: Stefan Monnier

> I'd be surprised if the compliance (or not) of Emacs's C code with
> specific versions of the C standard would make any difference to
> a newcomer.

> If you describe a concrete problem linked to being "not C17 compliant",
> then maybe we can start thinking about a plan.

I had heard of studies showing how most bugs in important
C software were resulting from UBs, i.e. having wrong assumptions
on what you write; and it is exacerbated the less standard compliant
the code is.  Hell, didn't they invent Rust just to avoid these
issues?  Keeping current is something like switching to Rust in this
case.  This and some other things mentioned on the thread seem
concrete issues to me, even if it they are very small in Emacs'
hierarchy of problems, so no rush.

> But so far all I've seen > is "compliance for its own sake".

Even when it made zero technical improvements, it would make soft
improvements especially for future.

> ... - The cruft accumulated over the years. ...

Language would help with this, I think.

> I don't even know of any single place where we're not "C17 compliant".

I'm confused, does this mean it is possible to fully build Emacs
with "-std=c17"?

> The difficulty in our C code comes from various aspects, none of which
> have much to do with the C language itself: ...
> ...
> Over the years, we've managed to reduce the use of macros ...

I appreciate this detailed information, thanks for your time.
I better save it for possible future use in documentation.

Re: Development Speed

[Stefan Monnier]

>> If you describe a concrete problem linked to being "not C17 compliant",
>> then maybe we can start thinking about a plan.
> I had heard of studies showing how most bugs in important
> C software were resulting from UBs, i.e. having wrong assumptions
> on what you write;

[ Never heard of such studies.  ]
It's definitely not the case that most of the bugs we fix in Emacs
result from UB.

There isn't much code in Emacs which suffers from UB, as far as I know.
That code is quite crucial, OTOH (it's typically the bit-twiddling we
use to manipulate the tagbits of `Lisp_Object` and the conservative
stack scanning): I don't know how to write this without going outside of
the specs of C (or Rust for that matter).

> Hell, didn't they invent Rust just to avoid these issues?

Not that I know, no.  It had to do with avoiding memory management and
concurrency bugs, as far as I know.  And yes I have heard of studies
that showed that memory safety and concurrency are the most common
sources of bugs in C-style languages.

>> But so far all I've seen is "compliance for its own sake".
> Even when it made zero technical improvements, it would make soft
> improvements especially for future.

Given that I still don't know of any place in Emacs's C code where we're
not compliant, I'm not sure that's the case.

>> ... - The cruft accumulated over the years. ...
> Language would help with this, I think.

I don't think so.  Such cruft is just the result of having to change
code you don't know or understand enough to be sure exactly what to do,
so you write your change so as to preserve as much of the previous
behavior to be on the safe side.  Language doesn't come into the picture
very much.  Test suites and "memory" (e.g. having the original author(s)
around) do to some extent.

>> I don't even know of any single place where we're not "C17 compliant".
> I'm confused, does this mean it is possible to fully build Emacs
> with "-std=c17"?

I'd assume so until proven otherwise.


        Stefan

Re: Development Speed

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org,  eliz@gnu.org
> Date: Thu, 23 Dec 2021 15:10:34 -0500
> 
> >> I don't even know of any single place where we're not "C17 compliant".
> > I'm confused, does this mean it is possible to fully build Emacs
> > with "-std=c17"?
> 
> I'd assume so until proven otherwise.

Not -std=c17, -std=gnu17.  We need some extensions, and cannot compile
with __STRICT_ANSI__ defined (which is what -std=c17 does, AFAIK).

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02457.html
From: Eli Zaretskii

> Not -std=c17, -std=gnu17. We need some extensions, and cannot compile
> with __STRICT_ANSI__ defined (which is what -std=c17 does, AFAIK).

But we are also restricted to some subset dialect of it, not to break
older settings, right?

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02453.html
From: Stefan Monnier

>> Language would help with this, I think.
> I don't think so. Such cruft is just the result of having to change
> code you don't know or understand enough to be sure exactly what to do,
> so you write your change so as to preserve as much of the previous
> behavior to be on the safe side. Language doesn't come into the picture
> very much. Test suites and "memory" (e.g. having the original author(s)
> around) do to some extent.

It is helpful to know what dialect you are dealing with when refactoring
such code, in terms of understanding and not causing new bugs.  Newer
language features might also help.  Of course other things mentioned
are a lot more significant:
> Language doesn't come into the picture very much.

But I guess this is getting too abstract, better for me talk over
examples when I'm over more of the code.

> There isn't much code in Emacs which suffers from UB, as far as I know.
> That code is quite crucial, OTOH (it's typically the bit-twiddling we
> use to manipulate the tagbits of `Lisp_Object` and the conservative
> stack scanning): I don't know how to write this without going outside of
> the specs of C (or Rust for that matter).

I see.  I wouldn't consider this "UB", I mean it literally is but when
it is intentional, functional on all targeted platforms, documented
and localized, it is just normal practice.  What I meant was of course
the unintended ones.

>> I had heard of studies showing how most bugs in important
>> C software were resulting from UBs, i.e. having wrong assumptions
>> on what you write
> [ Never heard of such studies. ]

>> Hell, didn't they invent Rust just to avoid these issues?
> Not that I know, no. It had to do with avoiding memory management and
> concurrency bugs, as far as I know. And yes I have heard of studies
> that showed that memory safety and concurrency are the most common
> sources of bugs in C-style languages.

Hm.  So, memory safety and concurrency mistakes in most cases do not
stem from "having wrong assumptions on what you write?"

Perhaps I should work on my wording to legally prove what I thought
a lot more clearly if some things I write here will get literal answers;
or get taunted.

Re: Development Speed

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 23:07:39 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02457.html
> From: Eli Zaretskii
> 
> > Not -std=c17, -std=gnu17. We need some extensions, and cannot compile
> > with __STRICT_ANSI__ defined (which is what -std=c17 does, AFAIK).
> 
> But we are also restricted to some subset dialect of it, not to break
> older settings, right?

Yes, we don't use stuff that would break C99 compilers.  We have
macros or conditionally-compiled code when newer features are
desirable, but not supported by older compilers.  However, the amount
of such conditional code is very small, as the new features are
generally not important for what we need to do in Emacs.  And those
new features are very few anyway, since C is stable and rarely if ever
changes in significant ways.

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Over the years, we've managed to reduce the use of macros (replaced by
  > inlinable functions) to some extent, partly thanks to improvement in
  > compilers, but it didn't change much to the code overall.

Why are inlinable functions superior to macros in regard to ease of
understanding the code?  I don't see how they help.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

>   > Over the years, we've managed to reduce the use of macros (replaced by
>   > inlinable functions) to some extent, partly thanks to improvement in
>   > compilers, but it didn't change much to the code overall.

> Why are inlinable functions superior to macros in regard to ease of
> understanding the code?  I don't see how they help.

+1

Re: Development Speed

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: xenodasein@tutanota.de, emacs-devel@gnu.org, eliz@gnu.org
> Date: Sat, 25 Dec 2021 00:16:03 -0500
> 
> Why are inlinable functions superior to macros in regard to ease of
> understanding the code?  I don't see how they help.

They make debugging slightly easier, because you can set a breakpoint
inside them and more easily step through the code.  In an unoptimized
build, they also appear in the backtrace, which also helps a little.

Re: Development Speed

[Stefan Monnier]

>   > Over the years, we've managed to reduce the use of macros (replaced by
>   > inlinable functions) to some extent, partly thanks to improvement in
>   > compilers, but it didn't change much to the code overall.
> Why are inlinable functions superior to macros in regard to ease of
> understanding the code?  I don't see how they help.

For example, you don't need to look at the definition of a function to
know how many times and in which context its actual arguments
are evaluated.


        Stefan

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >  It is only something someone
  > who's spent years on maintaining Emacs can know.  And there are
  > some things not written at all, for example RMS in this subject
  > mentioned a significant issue on some old hardware support.

If there are places in the Emacs sources for which it is important
to know this, I think the information that is crucial to tell people
would be why certain specific things should not be changed.

But what would those things?  Probably not small things in C code.
The versions of GNU/Linux we run on these machines are not old.  New
versions continue to support them.  They will get newer GCC versions
just as other GNU/Linux users do.

What these machines won't get is any faster.

Thus, the thing we need to remember is, "Don't assume that the
computer is as fast as a 2012 laptop, let alone as fast as a 2022
laptop."
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Sean Whitton]

Hello,

On Thu 23 Dec 2021 at 11:35AM -05, Stefan Monnier wrote:

> According to any of the C standards, Emacs is just one large undefined
> behavior.

Would you mind expanding on this remark briefly?  What sort of undefined
behaviour do you have in mind?

-- 
Sean Whitton

Re: Development Speed

[Stefan Monnier]

>> According to any of the C standards, Emacs is just one large undefined
>> behavior.
> Would you mind expanding on this remark briefly?  What sort of undefined
> behaviour do you have in mind?

Scanning the stack and playing with the lowest 3 bits of pointers come
to mind.  These are UB, and in C as soon as one UB is encountered during
execution, everything else from now on is potentially UB (more
specifically, the C standard allows the interpretation that a UB
operation does literally anything, including never terminating and
behaving eerily like your program).


        Stefan

Re: Development Speed

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> According to any of the C standards, Emacs is just one large undefined
>>> behavior.
>> Would you mind expanding on this remark briefly?  What sort of undefined
>> behaviour do you have in mind?
>
> Scanning the stack and playing with the lowest 3 bits of pointers come
> to mind.  These are UB, and in C as soon as one UB is encountered during
> execution, everything else from now on is potentially UB (more
> specifically, the C standard allows the interpretation that a UB
> operation does literally anything, including never terminating and
> behaving eerily like your program).

Yes, and in recent years a new breed of compiler engineers apply the
rule that if UB is found:

1. they are not in the obligation to tell you.

2. from there on the compiler is free to do the most bizarre things you
   can't imagine on its optimization passes, generating machine code
   that in no way corresponds to your intent.

This is causing much pain and chagrin on every major compiler release.
To be fair, it is also helping to educate many programmers and improve
their respective code bases.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02139.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Wed, 22 Dec 2021 14:41:18 +0200

> If you show the code that you tried...

My example was finding out that I couldn't create a minibuffer frame
from terminal, either to use it as the second background frame in the
terminal, or possibly to display it in a second terminal or GNU Screen
side by side.

> No, they don't.

> They don't even if the behavior is the same (why is that unfortunate?)
> or if it is not the same (assuming the differences are either
> self-evident or documented).

> No, there should be (ideally) only one set. Applications should be
> free from dealing with this distinction as much as possible.

IIRC there are other features like (images? svg? videos?)
that which suggest that terminal and graphical interfaces are already
diverged and have different capabilities, as they should, by their
nature.  Otherwise, why have functions like "display-graphic-p"?

> Maybe you should report a bug to the developers of that package,
> then. The Emacs development philosophy is what I described

My personal preference is using Emacs as a terminal editor most of the
time, and I would be all for Emacs being a terminal-first software,
but my impression is that it simply isn't, anymore.  However, this
doesn't mean that I consider GUI Emacs a bad idea.  Relevant:
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02034.html

Forgive my over-enthusiasm but I really care about Emacs being a
great terminal editor.  The only usable ones out in the wild right
now are Emacs and Vim.  As the world rushes to slap foundational
software like text editors inside friggin' web browsers, and Vim
having g0t_f0rk'd, this is the time to strike.

Re: Development Speed

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 16:21:29 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> > If you show the code that you tried...
> 
> My example was finding out that I couldn't create a minibuffer frame
> from terminal, either to use it as the second background frame in the
> terminal, or possibly to display it in a second terminal or GNU Screen
> side by side.

How did you try doing that?  Can you show some simple Lisp that I
could try?

> > No, there should be (ideally) only one set. Applications should be
> > free from dealing with this distinction as much as possible.
> 
> IIRC there are other features like (images? svg? videos?)
> that which suggest that terminal and graphical interfaces are already
> diverged and have different capabilities, as they should, by their
> nature.  Otherwise, why have functions like "display-graphic-p"?

For the few situations where the ideal is not really achievable.  But
that those exist doesn't mean we gave up on the ideal, just that we
are realists.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02204.html
From: Eli Zaretskii

> How did you try doing that?  Can you show some simple Lisp that I
> could try?

I don't have it anymore but AFAIR I tried to create a frame using the
attribute (minibuffer . only).  I also vaguely remember Elisp manual
mentioning that it won't work on a text terminal, but forgot where it
is.

Re: Development Speed

[Eli Zaretskii]

> Date: Thu, 23 Dec 2021 14:57:33 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org
> 
> > How did you try doing that?  Can you show some simple Lisp that I
> > could try?
> 
> I don't have it anymore but AFAIR I tried to create a frame using the
> attribute (minibuffer . only).  I also vaguely remember Elisp manual
> mentioning that it won't work on a text terminal, but forgot where it
> is.

Then I think this is the expected behavior: Emacs in general silently
ignores frame parameters that the frame or the display don't support.
It's a general behavior trait wrt frame parameters.

Development Speed

[xenodasein--- via Emacs development discussions.]

  Over some time now I have been trying to familiarize myself with Emacs
code-base and to follow emacs-devel.  I have an observation I would like to
ask about, because of course I alone can not assess the level of it's validity
as a mere mortal who doesn't have the man-hours spent on Emacs internals.

  Is Emacs developing too fast?  Contributions seem to focus on increasing
code size rather than reducing it, on adding features and not on
"paying technical debt"?  Maybe these tendencies oscillate healthily over
years and I only observed a period of the former.

  Especially the graphical parts seem to suffer from high-coupling and
low-cohesion?  Where for example the Neovim project seems to have the ability
to arbitrarily change what GUI implementation it uses. This mail seems to have
the same observation about GUI situation:
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01866.html

  I couldn't find a "milestones" type of guide, and do not know of future
plans except the ones in TODO file, so maybe there is something regarding to
this topic?

  Large-scale refactoring would make it possible to pursue TODO list items
like "Emacs as word processor" or "Concurrency", or allow us to use C17?

Thoughts?

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

>   Especially the graphical parts seem to suffer from high-coupling and
> low-cohesion?  Where for example the Neovim project seems to have the ability
> to arbitrarily change what GUI implementation it uses.

We certainly have the same ability in Emacs.  I was able to develop a
fully functional graphical port to Haiku in less than 2 months.

>   Large-scale refactoring would make it possible to pursue TODO list items
> like "Emacs as word processor" or "Concurrency", or allow us to use C17?

Refactoring for refactoring's sake never accomplishes much, and why
should we use C17?  What advantages does it hold?

Thanks.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01900.html
From: Po Lu
Date: Mon, 20 Dec 2021 08:31:18 +0800

> We certainly have the same ability in Emacs.  I was able to develop a
> fully functional graphical port to Haiku in less than 2 months.

I fail to see how this is accurate or relevant.

> Refactoring for refactoring's sake never accomplishes much

I don't know what refactoring for refactoring's sake is but;
What I mention is primarily done to reduce manhours needed to achieve
some things and and make new contributions easier/possible.
If making changes take too long, it can also indicate that the project is dead.
Or again from Neovim's example, could cause social issues, forks.
Software engineering textbooks have more to say on the topic.

> and why should we use C17?  What advantages does it hold?

This is a legitimate question we can assess.
Features like restricted pointers could improve performance?
But I think the better question is what is the excuse for striving not to
keep up with the latest language standard? (Assuming someone wants to work on
it.)

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I fail to see how this is accurate or relevant.

It shows that you don't need major refactoring to be able to add a new
GUI port of Emacs.

> I don't know what refactoring for refactoring's sake is but;
> What I mention is primarily done to reduce manhours needed to achieve
> some things and and make new contributions easier/possible.

I find any kind of rewrite to increase the number of manhours needed to
achieve things.  Especially when Emacs is involved.

> This is a legitimate question we can assess.  Features like restricted
> pointers could improve performance?  But I think the better question
> is what is the excuse for striving not to keep up with the latest
> language standard? (Assuming someone wants to work on it.)

I think we already use restricted pointers (including the GCC extension
for it) when they are available, as we do with some other features of
newer C standards, such as `_Noreturn'.

There is no "excuse" needed to not drop older language standards, when
the new one is not even universally available.  For example, it wasn't
really available on Haiku until this month, and even now the standard
library (libroot) seems to lack support for some of its features.

We dropped K&R because nobody was using a K&R compiler to build Emacs,
and because it didn't build with such a compiler either.  I regularly
see people building Emacs with a C99 compiler, and even more people
building with a C11 compiler.

For example, I don't think there's a version of GCC that will compile
the DJGPP port and supports C17 either.

Re: Development Speed

[Philip Kaludercic]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01900.html
> From: Po Lu
> Date: Mon, 20 Dec 2021 08:31:18 +0800
>
>> and why should we use C17?  What advantages does it hold?
>
> This is a legitimate question we can assess.
> Features like restricted pointers could improve performance?
> But I think the better question is what is the excuse for striving not to
> keep up with the latest language standard? (Assuming someone wants to work on
> it.)

I think the main issue is that by raising the language standard, you
break compatibility with systems that do not provide the compiler yet.

-- 
	Philip Kaludercic

Re: Development Speed

[Stefan Monnier]

Regarding paying technical debt, we could do a lot more of it, indeed,
but it takes time and effort and is hard to do without introducing
backward incompatible changes.

More importantly, we can't force people to do it.

This said, I think a lot of the work Emacs maintainers do (as opposed
to developers of 3rd party packages) is indeed just that.  It's just
that some of our debt are "too hard to tackle", so we focus on the
smaller things instead :-(

>> and why should we use C17?  What advantages does it hold?
> This is a legitimate question we can assess.

We have slowly moved from K&R C to ANSI C to newer versions of the
standard over the years, tho by and large we don't really pay attention
to particular versions of the standard but rather to specific features,
since the main issue is whether it's supported without too many bugs in
the various C compilers that we can expect people to use to build Emacs.

> Features like restricted pointers could improve performance?

My guess is that you're going to have a hell of a time coming up with
a contorted enough benchmark for such an improvement to be reliably
measurable in Emacs's code.

If it can lead to cleaner code and/or better errors&warnings, I'm all
for it, but I don't expect performance improvements to come from
the compiler.

> But I think the better question is what is the excuse for striving not
> to keep up with the latest language standard? (Assuming someone wants
> to work on it.)

I suggest you choose your words more carefully: "excuse" above implies
you think we lie, which doesn't seem like a good starting point for an
honest and constructive conversation.


        Stefan

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: list-was-down?
From: Lars Ingebrigtsen
Date: -

> Yes, I don't think that's accurate. (But it's certainly the impression
> you get when reading emacs-devel, so it's understandable why you'd think
> so.)

> There's an enormous amount of maintenance work going on in Emacs
> development.

I have indeed read the 10% series, and the monumental effort speaks for
itself. I also see commits from lots of people fixing and tidying things up
everyday, it's great. My sincere thanks as an Emacs user.

I only know of the communication through lists.gnu.org and the TODO file
and I missed any large scale, coordinated plans to structural changes.
I do not mean to say those must exist; but to merely inquire whether there
should be any such, or if they exist or are they documented and can be
accessed without directly requesting comments.

Quoting: list-was-down?
From: Stefan Monnier
Date: -

> Regarding paying technical debt, we could do a lot more of it, indeed,
> but it takes time and effort and is hard to do without introducing
> backward incompatible changes.

> More importantly, we can't force people to do it.

> This said, I think a lot of the work Emacs maintainers do (as opposed
> to developers of 3rd party packages) is indeed just that. It's just
> that some of our debt are "too hard to tackle", so we focus on the
> smaller things instead :-(

This is exactly what I thought I understood about the situation, feels good
to have been able to send at least some thoughts through, from all
my gibberish :)

> ...
> If it can lead to cleaner code and/or better errors&warnings, I'm all
> for it, but I don't expect performance improvements to come from
> the compiler.

I see, that makes sense. Thanks.

> I suggest you choose your words more carefully: "excuse" above implies
> you think we lie, which doesn't seem like a good starting point for an
> honest and constructive conversation.

That wasn't my intention at all, apologies for any offense by mistake.
I am aware of my need of tone tuning; second language problems. I welcome
tips like this, please don't refrain.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: list-was-down?
From: Po Lu
Date: -

> I looked at neovim, and in fact, I tried to use it for around a year and
> half, and my typical response to these questions is "let's wait for
> neovim to grow as old as Emacs, and see what happens to it".

> Neovim is IMO still very immature: for example, it still doesn't have
> the ability to open multiple frames or display images and multiple fonts
> in single window, which is a limitation shared with Vim, a relatively
> unsophisticated editor.

I completely agree, what I refer to is modularity of it's GUI, on that front
it is better, on anything else it is as you said.

> Most of what you read in a modern software engineering book doesn't
> apply to Emacs. Not to mention that those books tend to be discredited
> as often as psychology books, which is a rather ominous sign.

I mean, there has to be something more to all that research other than just
"Yo, it's like, psychology, man."

> Nobody running a modern GNU/Linux system will realistically suffer the
> deficiencies of such a platform. Care to list some?

Anything that will have been caused by not using latest the C?  Could mean
more bugs, less features...  M-x butterfly

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> I completely agree, what I refer to is modularity of it's GUI, on that front
> it is better, on anything else it is as you said.

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.

>> Nobody running a modern GNU/Linux system will realistically suffer the
>> deficiencies of such a platform. Care to list some?

> Anything that will have been caused by not using latest the C?  Could
> mean more bugs, less features...

Details, please.  We want to fix any bugs that crop up anywhere, and I
don't think we're missing out on any features.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

(This is a resend, it got lost when list was down.)

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01930.html
From: Po Lu
Date: Mon, 20 Dec 2021 13:12:40 +0800

First, thanks for your input on this, I really appreciate it.

> It shows that you don't need major refactoring to be able to add a new
> GUI port of Emacs.

Please take a look at Neovim, there is no comparison.
Also the entanglement of TUI and GUI; there is no clear separation without
breaking a lot of lisp code. For example trying to make a minibuffer frame on TUI
just returns nil, as they use the same functions.

> I find any kind of rewrite to increase the number of manhours needed to
> achieve things. Especially when Emacs is involved.

Maybe Emacs lives in a dimension where SE principles and research don't apply,
and if you see no room for improvement whatsoever so be it.

> I think we already use restricted pointers...
> ...
> I regularly see people building Emacs with a C99 compiler,
> and even more people building with a C11 compiler.
> For example, I don't think there's a version of GCC that will compile
> the DJGPP port and supports C17 either.

AFAIK there is almost no visible difference between C11 and C17; a
bug-fix release. And if features like you described are common then Emacs is
already mostly there. Nice.

> There is no "excuse" needed to not drop older language standards, when
> the new one is not even universally available.

Of course the targeting a platform without support is a valid reason but
making GNU/Linux or Windows users suffer the deficiencies of a platform
that cannot compile C11 in this day and age is somewhat cruel IMO.

We needn't use the whole C runtime but the core language should be fair game.

Re: Development Speed

[Po Lu]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

> (This is a resend, it got lost when list was down.)

FWIW, I think I already replied.

Re: Development Speed

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 11:25:06 +0100 (CET)
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> Please take a look at Neovim, there is no comparison.

Neovim is very young.  Emacs is being developed 4 times as long as
Neovim.  Let's talk when Neovim is comparably old (if it's still
around at that time).

> Also the entanglement of TUI and GUI; there is no clear separation without
> breaking a lot of lisp code. For example trying to make a minibuffer frame on TUI
> just returns nil, as they use the same functions.

This is a feature: Lisp programs almost never need to know whether
they run on text-mode or GUI displays.  If a Lisp program had to ask
on every step whether the display is TTY or GUI, the application could
would be much more complex and hard to read and maintain.  It used to
be that way at some distant past, but we deliberately implemented most
of the GUI features on TTYs: multiple frames, colors (with transparent
translation of X colors), mouse support, menus and dialogs -- in order
to eliminate most of the differences on the Lisp level.  I'm amazed
that you think this is a disadvantage in Emacs.

> > I regularly see people building Emacs with a C99 compiler,
> > and even more people building with a C11 compiler.

We didn't yet move to C11, we require C99.

> > There is no "excuse" needed to not drop older language standards, when
> > the new one is not even universally available.
> 
> Of course the targeting a platform without support is a valid reason but
> making GNU/Linux or Windows users suffer the deficiencies of a platform
> that cannot compile C11 in this day and age is somewhat cruel IMO.

We are not talking about platforms, we are talking about GNU/Linux
systems that still use old GCC versions.  There are quite a lot of
those.  Not everyone runs the latest alpha of the Linux kernel with
the latest snapshot of GCC.  One of the worst "surprises" when
building a new version of a package is to find out it no longer
supports your compiler/linker/libraries, because that's a beginning of
a long journey down the rabbit hole of upgrading your entire system,
and finally probably the hardware as well.  There's nothing nastier
software developers can do to their users than being the tail that
wags the dog.

I'm very happy to say that Emacs was never like that, and I hope it
will never change in this regard.

Re: Development Speed

[Lars Ingebrigtsen]

xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
writes:

>   Is Emacs developing too fast?  Contributions seem to focus on increasing
> code size rather than reducing it, on adding features and not on
> "paying technical debt"?  Maybe these tendencies oscillate healthily over
> years and I only observed a period of the former.

Yes, I don't think that's accurate.  (But it's certainly the impression
you get when reading emacs-devel, so it's understandable why you'd think
so.)

There's an enormous amount of maintenance work going on in Emacs
development.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Development Speed

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   Is Emacs developing too fast?  Contributions seem to focus on increasing
  > code size rather than reducing it, on adding features and not on
  > "paying technical debt"?  Maybe these tendencies oscillate healthily over
  > years and I only observed a period of the former.

I think we sometimes go too fast.  However, I don't think we should
be putting a priority on making the code smaller.  Most of the time,
smaller won't do users much good.

There may be specific areas where some cleaning up would be desirable
-- what you think of as "paying technical debt".  But we should limit
that to specific aspects where it could be a big improvement.  Every
change risks causing new bugs.  I think most cleanups would be
counterproductive even if they do make cleaner code.  

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Development Speed

[Eli Zaretskii]

On December 21, 2021 6:15:29 AM GMT+02:00, Richard Stallman <rms@gnu.org> wrote:
> 
> I think we sometimes go too fast.  However, I don't think we should
> be putting a priority on making the code smaller.  Most of the time,
> smaller won't do users much good.
> 
> There may be specific areas where some cleaning up would be desirable
> -- what you think of as "paying technical debt".  But we should limit
> that to specific aspects where it could be a big improvement.  Every
> change risks causing new bugs.  I think most cleanups would be
> counterproductive even if they do make cleaner code.  
> 

IMNSHO, there's no such thing as "too fast development".  There's development that makes too many mistakes at a too high rate, but that's not what we have in Emacs, far from that.

As for the risks of excess cleanups: I share your concern, but if some contributor likes cleaning up code, and he/she does a clean job (pun intended), it is better to sustain that risk than risking to lose that contributor, who might one day proceed to developing new features.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01977.html
From: Richard Stallman
Date: Mon, 20 Dec 2021 23:15:29 -0500

> I think we sometimes go too fast. However, I don't think we should
> be putting a priority on making the code smaller. Most of the time,
> smaller won't do users much good.

I agree if the amount of regular contributions and contributors scale
up with the code size.  Otherwise, wouldn't compromises be necessary?

> There may be specific areas where some cleaning up would be desirable
> -- what you think of as "paying technical debt". But we should limit
> that to specific aspects where it could be a big improvement. Every
> change risks causing new bugs. I think most cleanups would be
> counterproductive even if they do make cleaner code.

That is true, they should be done when a direction necessitates them.
Ones that came to my mind were the TODO items I mentioned, but they
are enormous.

Re: Development Speed

[Eli Zaretskii]

> Date: Tue, 21 Dec 2021 12:09:36 +0100 (CET)
> Cc: Emacs Devel <emacs-devel@gnu.org>
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> > I think we sometimes go too fast. However, I don't think we should
> > be putting a priority on making the code smaller. Most of the time,
> > smaller won't do users much good.
> 
> I agree if the amount of regular contributions and contributors scale
> up with the code size.  Otherwise, wouldn't compromises be necessary?

Our Git repository is public, so everyone can study its statistics.
Do you have any evidence that the rate of changes and contributions in
Emacs deteriorates with the years?

> That is true, they should be done when a direction necessitates them.
> Ones that came to my mind were the TODO items I mentioned, but they
> are enormous.

That's a tribute to the many features that we already have, and their
development over the years.  It isn't like we have a lot of holes in
the feature set filling which is a low-hanging fruit.

Re: Development Speed

[xenodasein--- via Emacs development discussions.]

Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02015.html
From: Eli Zaretskii
Subject: Re: Development Speed
Date: Tue, 21 Dec 2021 16:52:13 +0200

> Our Git repository is public, so everyone can study its statistics.
> Do you have any evidence that the rate of changes and contributions in
> Emacs deteriorates with the years?

I did not necessarily want to imply that it was an existing problem,
just a what-if.  I do not have it but I suppose some numbers could be
produced using amounts of active contributors, contributions, total LOC,
etc. and ratios as evidence?  There are also software that analyze code
complexity using metrics such as cyclomatic complexity I believe.

My reason own to bring it up was that I absolutely hated what I saw
here: GOOGLE ALERT https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01yp0m,%2Fm%2F07zh7,%2Fm%2F0134xwrk

Re: Development Speed

[Eli Zaretskii]

> Date: Wed, 22 Dec 2021 01:55:56 +0100 (CET)
> From: xenodasein@tutanota.de
> Cc: emacs-devel@gnu.org, Richard Stallman <rms@gnu.org>
> 
> Quoting: https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg02015.html
> From: Eli Zaretskii
> Subject: Re: Development Speed
> Date: Tue, 21 Dec 2021 16:52:13 +0200
> 
> > Our Git repository is public, so everyone can study its statistics.
> > Do you have any evidence that the rate of changes and contributions in
> > Emacs deteriorates with the years?
> 
> I did not necessarily want to imply that it was an existing problem,
> just a what-if.  I do not have it but I suppose some numbers could be
> produced using amounts of active contributors, contributions, total LOC,
> etc. and ratios as evidence?  There are also software that analyze code
> complexity using metrics such as cyclomatic complexity I believe.

We have enough real issues to take up all my free time, I don't need
hypothetical what-if's added to them.  You are welcome to produce such
numbers, and if you think they are of interest, post them.

> My reason own to bring it up was that I absolutely hated what I saw
> here: GOOGLE ALERT https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01yp0m,%2Fm%2F07zh7,%2Fm%2F0134xwrk

The challenge is to identify the _real_ causes of that, and then see
what we can do about them.