GNU bug report logs - #51658
[PATCH] Haiku port (again)

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: bug#51658: [PATCH] Haiku port (again)
Date: Sun, 14 Nov 2021 17:36:01 +0800

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.