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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4