Re: Development Speed

[xenodasein]

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