Re: Development Speed

[Eli Zaretskii <eliz@gnu.org>]

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