emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Development Speed


From: Po Lu
Subject: Re: Development Speed
Date: Mon, 20 Dec 2021 13:12:40 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]