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

[xenodasein]

Nov 30, 2022, 16:23 by eliz@gnu.org:

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

I also repeatedly say adding completely new things like treesitter
is encouraged, because someone(tm) will maintain them supposedly.
Problem is tackling what's already in there, which happens almost
never compared the former.  Overhauling display is going to require
that, I'd love to see how it would go without touching the
infrastructure or without the friction I've seen with simple mention
of it before even changing code.  If someone attempts that it would
make it simpler to believe you, because I am discouraged to take
the first step.