I fucking hate feature macros. Egregious discharge of our
division-of-labor-obsessed society. People should be able to introduce
names. People should be able to give up names to lower levels of
abstraction when they encounter conflicts.
Feature macros seem to exist[1] to support more than two levels of
abstraction. You try to build, one of your libraries fails to build
because of a conflict between it and one level down. You don't want to
modify this library. Just fucking https://catern.com/change_code.html
already. But no, I have to litter my code with feature macros even
though I just want the abstraction the original library provides.
[1] https://man7.org/linux/man-pages/man7/feature_test_macros.7.htmlhttps://lwn.net/Articles/590381
NetBSD still uses curses by default. One _could_ install ncurses, but I
don't have access to a NetBSD box with permissions to install ncurses,
so I'm experimenting to see how far we can get with just curses. So far
most of the apps seem to work, with the exception of one bug that I'll
commit next.
This is a complete mess. I want to abstract reading multiline strings
behind a function, but the lookahead requirements for that are quite
stringent. What's a reasonable abstraction here?
I really wanted to avoid getting into defining or parsing new file
formats. However, using the entire power of Lua is not ideal, as
described earlier in Konrad Hinsen's bug. In addition to everything
else, it's a vector for arbitrary code execution when someone loads an
untrusted image.
I could use JSON, but it requires ugly string escaping. Seems cleaner to
just use YAML. But YAML is complex and needs its own dependencies. If
I'm going to do my own, might as well make the multi-line string format
really clear.
I can't yet write the new format.
Kartik K. Agaram