Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning

[Eli Zaretskii]

> Date: Wed, 30 Nov 2022 12:51:07 +0100 (CET)
> Cc: Björn Bidar <bjorn.bidar@thaodan.de>, emacs-devel@gnu.org
> From: xenodasein--- via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> You must keep in mind that big contributions like this must have a
> foundation if there will be any hope of them even happening.  For
> example I can almost imagine the answers if I suggested separating
> some translation units instead of using #ifdef's every five lines,
> so I won't don't worry.  Or take as example the recent discussion on
> macros.  It won't make much of a difference indeed if some line is
> a function or a macro, issue is the resistance to even simple changes
> like that; it implies the impossibility of something not as simple.
> You can say no it doesn't, regardless that is the picture it paints.
> I remember Eli requesting not to change the location of some function
> on the grounds that it will now be harder to find where it is.

I don't understand how separating some translation units or
changing/replacing macros are related to development of any significant
feature in Emacs.  Any such significant new feature will have tons of new
code which you can factor as you see fit; if you do a clean job, no one will
argue with how you define functions and macros.  And in any such new code, I
don't see how it matters whether, say, MATRIX_ROW_BOTTOM_Y is a macro or a
function: you just use it and that's it.

IOW, adding important new features to Emacs doesn't need to change how we
use our infrastructure and whether something is a macro or not.  They are
completely orthogonal issues.  Our low-level functions and macros don't
prevent anyone from adding features, and in case a function or a macro
really needs to be refactored or accept additional arguments to enable a new
feature, no one will object (again, provided that you do a clean job).  For
a recent example, see treesit.c.

So this rant of your is completely unclear to me.