Re: Development Speed

[xenodasein]

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?