bug#51658: [PATCH] Haiku port (again)

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Too bad.  IMNSHO, that's a ticking time bomb, and it will certainly
> bite us at some point, since mixing C and C++ is tricky and requires a
> lot of diligence.  It also means that you will probably be unable to
> use any compiler but GCC (or whatever is currently supported by
> Haiku), since different C++ compilers are generally
> binary-incompatible.

AFAIU, the Haiku developers only support GCC for compiling C++ code, as
they have a requirement to keep support for old BeOS software, which
depends on the GCC ABI.

If that changes in the future, it would only be alongside a major change
in the operating system's other aspects, that would break the build
anyway.

> Since you later say Cairo is unreliable, why not drop Cairo?

What I meant by "unreliable" is that the Haiku developers tend to tweak
their Cairo package in various manners, which breaks the Emacs build.

People building Cairo themselves won't experience this problem, but
building the BeOS cairo backend is... tricky, to say the least.  I
managed to get it to work, but there is a lot of pain involved in it
that I wouldn't want to repeat.

The Haiku developers have a package repository and build automation
system that would make this easy, should they ship the Haiku port of
Emacs in the future.  (At present, they only ship Emacs built to run in
a TTY.)

So it is useful to have Cairo around, for people whom it is useful, but
if not, it would be good to have something to fall back to.

> And that still leaves us with 3 backends, IIUC.  Why not just one?

Well, one of those backends is simply a HarfBuzz variant of the other,
which is how xftfont and ftcrfont do it, and IIUC, that's how it works
under MS-Windows too.

So, if we keep only the haikufont backend (for Haiku users who don't
want to install FreeType or Cairo), and one of `ftbe' or cairo font
support, there will really just be two font backends.

(haikufont.c and related support functions in haiku_font_support.cc use
the BFont API, which is the native font API on Haiku, but doesn't
support fancy text shaping or HarfBuzz, not unlike X11 Core Fonts.)

Aside from not depending on Cairo or FreeType, which are not always
available on Haiku, it also comes with the advantage of being fast even
on remote sessions (not unlike X11 remote access), as characters drawn
are sent down the wire as plain text, instead of as bitmap data, which
is very slow when operating over a remote connection.

So I think it will be useful as a fallback in many cases.

> Let me clarify why I insist on those issues: this port's usability
> will depend crucially on its support by the developers who are
> interested in Haiku, and that's for now just you.  Any decrease in the
> level of support will most probably mean the port will bitrot and die,
> given the fast pace of Emacs development.  So every feature that
> doesn't absolutely have to be there is better removed, because having
> too many supported configurations makes the code difficult to
> understand and test, and thus fewer people will be able to support it.
> Please keep this in mind when you insist on optional non-essential
> features.  From experience, a port or a feature that is not supported
> well enough bitrots very quickly around here.

Thanks, I understand the problem.  I was tempted to add many features,
but refrained from doing so for precisely this reason.

> So my suggestion is to choose wisely which features you really need to
> keep.

Yes, thanks.