Eli Zaretskii writes: > Is haikufont so different from the other font infrastructures that you > couldn't do it? Supporting HarfBuzz usually needs just a small number > of functions, as the basics are already in hbfont.c. > > Or maybe you have specific questions about this, in which case please > ask them. BFont seems to be too basic. Someone has given me details on using FreeType and HarfBuzz in Haiku applications and I plan to look at that. > OK, but then please add a comment there with this information, so this > isn't forgotten if and when we change what we do for w32. Done. > AFAIU, cl, KCC, xlC, and aCC aren't GCC, right? Yeah, I think I was a bit carried away at that time. > I was talking about C source files and headers not specific to Haiku: > those don't have 'extern "C"' guards anywhere. They could fail to > compile with a C++ compiler. AFAIK, no Emacs header files are included by the haiku_*_support files, which are the only files compiled with a C++ compiler. The only interface between these files and the rest of Emacs is the asynchronous IO mechanism in haiku_io.c, and the header haiku_support.h, both of which are vetted to work. > Hmm... maybe. But then I guess I'm confused: what does the automatic > detection of Haiku do, if one needs --with-be-app to have the > windowing code? IOW, why don't you assume --with-be-app if the > automatic detection of Haiku succeeds? I think it owes to the fact that the Haiku windowing backend is not entirely complete. Namely, the font driver needs work, and there are some things I haven't quite worked out, such as child frames. > Not all of them. Fair enough.