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

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Let's use Cairo with HarfBuzz instead, then.  I don't want to use
> libm17n-flt in any new code: it is unmaintained and has known
> problems.

Okay, I deleted the part of configure.ac that checks for m17n-flt when
using Cairo on Haiku.  Thanks.

>> The "option key" and "command key" in Haiku are unusual concepts not
>> found in other systems, so it's worthwhile to mention it here.

> But the users of Haiku know about those keys, don't they?  The Emacs
> manual is not supposed to teach the users about their systems, it's
> supposed to teach them about Emacs.

That is correct, but the correspondence between those keys and the Emacs
keys is not immediately obvious, so I thought it would be worth
mentioning.

>> The variable used is different, as it doesn't make sense to name a Haiku
>> variable `x-gtk-...'

> But you already describe the variable elsewhere, so why does it have
> to be mentioned in this appendix as well?

I moved the description of that variable to the appendix, because it
makes more sense to have it there instead.

>> >> +@table @key
>> >> +@item haiku-refs-found
>> >> +This event is received whenever the operating system tells Emacs to
>> >> +open a file, such as when a file's icon is dropped onto the
>> >> +@code{Emacs} binary in the Tracker, or when a file is dropped onto a
>> >> +frame.  The event itself is a list, the second item of which is a
>> >> +string containing the path of the file to be opened.
>> 
>> > Why isn't this treated as drag-and-drop on other platforms?  Then you
>> > won't need Haiku-specific documentation and events.
>> 
>> It might not specifically be a drag event: for example, the Tracker
>> could ask Emacs to open a file, because the user selected it from the
>> "Recent files" menu.

> The result is the same: Emacs visits a file.  I don't think I
> understand why these events should be exposed to Lisp.

But drag-n-drop events have a POSITION argument, while a position isn't
available when the system sends Emacs a B_REFS_FOUND message.

> Which part is specific to X?

The entire file is preconditioned on HAVE_X_SM, and is based on things
such as `SmcInteractDone' that only make sense on X.

It also relies on functions like `emacs-session-save', which are in
x-win.el and rely on X specific code.

> And if the current implementation uses X-specific code, it just means
> the implementation should be extended to allow other platforms trigger
> the same mechanism.  Any reason Haiku couldn't do that?

Haiku doesn't have a session manager, so it doesn't make sense to use
the mechanism in xsmfns.c: the system doesn't try to restore Emacs when
the system restarts, or to save Emacs's session information when it
quits.

It tells the application that it's about to quit as a courtesy, so it
can perhaps run a few popup dialogs informing the user to save his
files.

> Having disparate platform-specific mechanisms for performing the same
> task is bad for maintenance and bad for documentation and users.  We
> should try to present as uniform UI as possible on all platforms, even
> when the internal details are different.

Otherwise, I agree, thanks.

> Then the text should explicitly mention Alt-TAB.

Thanks, I'll update the text to say that.

> I realize that many projects document functions in header files, but
> we don't.  Our style is to document them in the *.c files instead.

Thanks, I will move the comments there instead.

>> >> +/* Haiku doesn't expose font language data in BFont objects.  Thus, we
>> >> +   select a few representative characters for each supported `:lang'
>> >> +   (currently Chinese, Korean and Japanese,) and test for those
>> >> +   instead.  */
>> >> +
>> >> +static uint32_t language_code_points[MAX_LANGUAGE][4] =
>> >> +  {{20154, 20754, 22996, 0}, /* Chinese.  */
>> >> +   {51312, 49440, 44544, 0}, /* Korean.  */
>> >> +   {26085, 26412, 12371, 0}, /* Japanese.  */};
>> 
>> AFAIK, `script-representative-chars' doesn't handle languages such as
>> Korean or Japanese, but I could be mistaken.
>
> Of course, it does.  It just goes by script, not by language.  But if
> script-representative-chars lacks some characters you need, we could
> add them as alternatives.

Makes sense, I think I see what I need in script_representative_chars
now.

>> It's used to report an error in Emacs that will cause it to abort
>> immediately afterwards, with some explanation as to why.  It will be
>> valuable for bug reports, as `addr2line', `gdb' and friends are hard to
>> set up on Haiku, and the output of the system debugger is not very
>> helpful with crashes in Emacs C++ code.  So I think it's OK.  (Something
>> similar is done in xterm to explain the GTK display disconnect abort
>> bug.)

> Is it guaranteed that Emacs has stderr stream connected to some file
> or device when it runs in GUI session?  If not, this stuff will be
> lost, and it might be a better idea to pop up a GUI dialog window with
> this text instead.

Yes, stderr is connected to syslog_daemon when launched from anything
other than a pseudo terminal, IIUC.

> I'd prefer to have it elsewhere.  We already have quite a mes with
> this in sysdep.c.

OK, I'll move it somewhere else.

> Will review this later.

Thank you!  I'll also work on implementing the changes I talked about
earlier later, as some of them involve rather large changes.

I'll post another patch once it's ready.