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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51658 in the body.
You can then email your comments to 51658 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Haiku port (again)
Date: Sun, 07 Nov 2021 19:29:32 +0800

[Message part 1 (text/plain, inline)]

OK, after using this port for more than a month now I can say it's
finally stable enough for heavy use.

I think all the major bugs have been ironed out now, so I'm submitting
it for inclusion.

I couldn't figure out how to turn multiple (hundereds) of git commits
into a single patch formatted like `git format-patch' would, so I
attached the output of `git diff' instead.

Please take some time to review the code and possibly install it.
Thanks!

Here is a commit message I wrote that should be appropriate:

Add support for the Haiku operating system and its window system 

* .gitignore: Add binaries specific to Haiku.

* Makefie.in (HAVE_BE_APP): New variable.
(install-arch-dep): Install Emacs and Emacs.pdmp when using Haiku.

* configure.ac: Detect and configure for Haiku and various related
 configurations.
(be-app, be-freetype, be-cairo): New options.
(HAVE_BE_APP, HAVE_BE_FREETYPE, HAIKU_OBJ, HAIKU_CXX_OBJ)
(HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(HAIKU, HAVE_TINY_SPEED_T): New define.
(emacs_config_features): Add BE_APP.

* doc/emacs/Makefile.in (EMACSSOURCES): Add Haiku appendix.

* doc/emacs/emacs.texi: Add Haiku appendix to menus and
include it.

* doc/emacs/haiku.texi: New Haiku appendix.

* doc/lispref/display.texi (Defining Faces, Window Systems): Explain
haiku as a window system identifier.
(haiku-use-system-tooltips): Explain meaning of system tooltips on
Haiku.

* doc/lispref/frames.texi (Multiple Terminals): Explain meaning of
haiku as a display type.
(Frame Layout): Clarify section for Haiku frames.
(Size Parameters): Explain limitations of fullwidth and fullheight
on Haiku.
(Management Parameters): Explain limitations of inhibiting double
buffering on builds with Cairo, and the inability of frames with
no-accept-focus to receive keyboard input on Haiku.
(Font and Color Parameters): Explain the different font backends
available on Haiku.
(Raising and Lowering): Explain that lowering and restacking frames
doesn't work on Haiku.
(Child Frames): Explain oddities of child frame visibility on Haiku.

* doc/lispref/os.texi (System Environment): Explain meaning of haiku
.
* etc/MACHINES: Add appropriate notices for Haiku.
* etc/NEWS: Document changes.
* etc/PROBLEMS: Document font spacing bug on Haiku.

* lib-src/Makefile.in: Build be-resources binary on Haiku.
(CXX, CXXFLAGS, NON_CXX_FLAGS, ALL_CXXFLAGS)
(HAVE_BE_APP, HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(DONT_INSTALL): Add be-resources binary if on Haiku.
(be-resources): New target.

* lib-src/be_resources: Add helper binary for setting resources on
the Emacs application.

* lib-src/emacsclient.c (decode_options): Set alt_display to "be"
on Haiku.

* lisp/cus-edit.el (custom-button, custom-button-mouse)
(custom-button-unraised, custom-button-pressed): Update face
definitions for Haiku.

* lisp/cus-start.el: Add haiku-debug-on-fatal-error and
haiku-use-system-tooltips.

* lisp/faces.el (face-valid-attribute-values): Clarify attribute
comment for Haiku.
(tool-bar): Add appropriate toolbar color for Haiku.

* lisp/frame.el (haiku-frame-geometry)
(haiku-mouse-absolute-pixel-position)
(haiku-set-mouse-absolute-pixel-position)
(haiku-frame-edges)
(haiku-frame-list-z-order): New function declarations.

(frame-geometry, frame-edges)
(mouse-absolute-pixel-position)
(set-mouse-absolute-pixel-position)
(frame-list-z-order): Call appropriate window system functions
on Haiku.

(display-mouse-p, display-graphic-p)
(display-images-p, display-pixel-height)
(display-pixel-width, display-mm-height)
(display-mm-width, display-backing-store)
(display-save-under, display-planes)
(display-color-cells, display-visual-class): Update type tests
for Haiku.

* lisp/international/mule-cmds.el (set-coding-system-map): Also
prevent set-terminal-coding-system from appearing in the menu bar
on Haiku.

* lisp/loadup.el: Load Haiku-specific files when built with Haiku,
and don't rename newly built Emacs on Haiku as BFS doesn't support
hard links.

* lisp/menu-bar.el (menu-bar-open): Add for Haiku.

* lisp/mwheel.el (mouse-wheel-down-event): Expect wheel-up on Haiku.
(mouse-wheel-up-event): Expect wheel-down on Haiku.
(mouse-wheel-left-event): Expect wheel-left on Haiku.
(mouse-wheel-right-event): Expect wheel-right on Haiku.

* lisp/net/browse-url.el (browse-url--browser-defcustom-type):
Add option for WebPositive.
(browse-url-webpositive-program): New variable.
(browse-url-default-program): Search for WebPositive.
(browse-url-webpositive): New function.

* lisp/net/eww.el (eww-form-submit, eww-form-file)
(eww-form-checkbox, eww-form-select): Define faces appropriately
for Haiku.

* lisp/term/haiku-win.el: New file.

* lisp/tooltip.el (menu-or-popup-active-p): New function declaration.
(tooltip-show-help): Don't use tooltips on Haiku when a menu is active.

* lisp/version.el (haiku-get-version-string): New function declaration.
(emacs-version): Add Haiku version string if appropriate.

* src/Makefile.in: Also produce binary named "Emacs" with Haiku resources
set.

(CXX, HAIKU_OBJ, HAIKU_CXX_OBJ, HAIKU_LIBS)
(HAIKU_CFLAGS, HAVE_BE_APP, NON_CXX_FLAGS, ALL_CXX_FLAGS): New
variables.

(.SUFFIXES): Add .cc.
(.cc.o): New target.
(base_obj): Add Haiku C objects.
(doc_obj, obj): Split objects that should scanned for documentation
into doc_obj.
(SOME_MACHINE_OBJECTS): Add appropriate Haiku C objects.
(all): Depend on Emacs and Emacs.pdmp on Haiku.
(LIBES): Add Haiku libraries.
(gl-stamp)
($(etc)/DOC): Scan doc_obj instead of obj
(temacs$(EXEEXT): Use C++ linker on Haiku.
(ctagsfiles3): New variable.
(TAGS): Scan C++ files.

* src/alloc.c (garbage_collect): Mark Haiku display.

* src/dispextern.h (HAVE_NATIVE_TRANSFORMS): Also enable on Haiku.
(struct image): Add fields for Haiku transforms.
(RGB_PIXEL_COLOR): Define to unsigned long on Haiku as well.
(sit_for): Also check USABLE_SIGPOLL.
(init_display_interactive): Set initial window system to Haiku on
Haiku builds.

* src/emacs.c (main): Define Haiku syms and init haiku clipboard.
(shut_down_emacs): Quit BApplication on Haiku and trigger debug
on aborts if haiku_debug_on_fatal_error.
(Vsystem_type): Update docstring.

* src/fileio.c (next-read-file-uses-dialog-p): Enable on Haiku.

* src/filelock.c (WTMP_FILE): Only define if BOOT_TIME is also
defined.

* src/floatfns.c (double_integer_scale): Work around Haiku libroot
brain damage.

* src/font.c (syms_of_font): Define appropriate font driver symbols
for Haiku builds with various options.

* src/font.h: Also enable ftcrfont on Haiku builds with Cairo.
(font_data_structures_may_be_ill_formed): Also enable on Haiku
builds that have FreeType or Cairo.

* src/frame.c (Fframep): Update doc-string for Haiku builds and
return haiku if appropriate.
(syms_of_frame): New symbol `haiku'.

* src/frame.h (struct frame): Add output data for Haiku.
(FRAME_HAIKU_P): New macro.
(FRAME_WINDOW_P): Test for Haiku frames as well.

* src/ftbefont.c: New file.
* src/ftcrfont.c (RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG): New macros.
(ftcrfont_draw): Add haiku specific code for BE_CAIRO builds.

* src/ftfont.c (ftfont_open): Set face.
(ftfont_has_char, ftfont_text_extents): Work around crash.
(syms_of_ftfont): New symbol `mono'.

* src/ftfont.h (struct font_info): Enable cairo fields for BE_CAIRO
builds, and add face and shape cache fields for ftbefont.

* src/haiku_draw_support.cc:
* src/haiku_font_support.cc:
* src/haiku_freetype.cc:
* src/haiku_io.c:
* src/haiku_select.cc:
* src/haiku_support.cc:
* src/haiku_support.h:
* src/haikufns.c:
* src/haikufont.c:
* src/haikugui.h:
* src/haikuimage.c:
* src/haikumenu.c:
* src/haikuselect.c:
* src/haikuselect.h:
* src/haikuterm.c:
* src/haikuterm.h: Add new files for Haiku windowing support.

* src/image.c: Implement image transforms and native XPM support
on Haiku.

(GET_PIXEL, PUT_PIXEL, NO_PIXMAP)
(PIX_MASK_RETAIN, PIX_MASK_DRAW)
(RGB_TO_ULONG, RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG, RED16_FROM_ULONG, GREEN16_FROM_ULONG)
(BLUE16_FROM_ULONG): Define to appropriate values on Haiku.

(image_create_bitmap_from_data): Add Haiku support.
(image_create_bitmap_from_file): Add TODO on Haiku.
(free_bitmap_record): Free bitmap on Haiku.
(image_size_in_bytes): Implement for Haiku bitmaps.
(image_set_transform): Implement on Haiku.
(image_create_x_image_and_pixmap_1): Implement on Haiku, 24-bit or
1-bit only.
(image_destroy_x_image, image_get_x_image): Use correct img and
pixmap values on Haiku.
(lookup_rgb_color): Use correct macro on Haiku.
(image_to_emacs_colors): Implement on Haiku.
(image_disable_image): Disable on Haiku.
(image_can_use_native_api): Test for translator presence on Haiku.
(native_image_load): Use translator on Haiku.
(imagemagick_load_image): Add Haiku-specific quirks.
(Fimage_transforms_p): Allow rotate90 on Haiku.
(image_types): Enable native XPM support on Haiku.
(syms_of_image): Enable XPM images on Haiku.

* src/keyboard.c (kbd_buffer_get_event)
(handle_async_input, handle_input_available_signal)
(handle_user_signal, Fset_input_interrupt_mode)
(init_keyboard): Check for USABLE_SIGPOLL along with USABLE_SIGIO.

(make_lispy_event, kbd_buffer_get_event)
(syms_of_keyboard): Handle special Haiku events.

* src/lisp.h (pD): Work around broken Haiku headers.
(HAVE_EXT_MENU_BAR): Define on Haiku.
(handle_input_available_signal): Enable if we just have SIGPOLL
as well.

* src/menu.c (have_boxes): Return true on Haiku.
(single_menu_item): Enable toolkit menus on Haiku.
(find_and_call_menu_selection): Also enable on Haiku.

* src/process.c (keyboard_bit_set): Enable with only usable SIGPOLL.
(wait_reading_process_output): Test for SIGPOLL as well as SIGIO
availability.

* src/sound.c (sound_perror, vox_open)
(vox_configure, vox_close): Enable for usable SIGPOLL as well.

* src/sysdep.c (sys_subshell): Enable for usable SIGPOLL.
(reset_sigio): Make conditional on F_SETOWN.
(request_sigio, unrequest_sigio)
(emacs_sigaction_init): Also handle SIGPOLLs.
(init_sys_modes): Disable TCXONC usage on Haiku, as it doesn't
have any ttys other than pseudo ttys, which don't support C-s/C-q
flow control.
(speeds): Disable high speeds if HAVE_TINY_SPEED_T.
(list_system_processes, system_process_attributes): Implement for
Haiku.

* src/termhooks.h (enum output_method): Add output_haiku.
(enum event_kind): Add HAIKU_REFS_FOUND_EVENT and
HAIKU_QUIT_REQUESTED_EVENT.
(struct terminal): Add Haiku display info.
(TERMINAL_FONT_CACHE): Enable for Haiku.

* src/terminal.c (Fterminal_live_p): Return `haiku' if appropriate.
* src/verbose.mk.in (AM_V_CXX, AM_V_CXXLD): New logging variables.

* src/xdisp.c (redisplay_internal, note_mouse_highlight): Return on
Haiku if a popup is activated.
(display_menu_bar): Return on Haiku if frame is a Haiku frame.

* src/xfaces.c (GCGraphicsExposures): Enable correctly on Haiku.
(x_create_gc): Enable dummy GC code on Haiku.

* src/xfns.c (x-server-version, x-file-dialog): Add Haiku specifics
to doc strings.

* src/xterm.c (syms_of_xterm): Add Haiku information to doc string.

[haiku-emacs.patch (text/x-patch, attachment)]

Message #8 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Tue, 09 Nov 2021 19:58:01 +0200

> Date: Sun, 07 Nov 2021 19:29:32 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> OK, after using this port for more than a month now I can say it's
> finally stable enough for heavy use.
> 
> I think all the major bugs have been ironed out now, so I'm submitting
> it for inclusion.
> 
> I couldn't figure out how to turn multiple (hundereds) of git commits
> into a single patch formatted like `git format-patch' would, so I
> attached the output of `git diff' instead.
> 
> Please take some time to review the code and possibly install it.

Thanks.

It's a large patch, so let's start with the general, a.k.a. "big"
aspects.

First, do we really need to use *.cc files and compile with a C++
compiler?  Is that a necessity?  AFAICT, the code in those *.cc files
is plain C, so why not use a C compiler, as we do on every other
platform?

Next, the font backend stuff: do we really need 5 (five) backends?
How about having just one: HarfBuzz+Cairo?  That's the direction we go
on other platforms, so how about making the Haiku code smaller and
simpler and support just that single backend, and drop all the older
ones?  I'd definitely won't want to drag the unmaintained libm17n-flt
into this port.

If you are okay with the above, could you please update the patch, so
that we could avoid reviewing code which eventually won't be
installed?

Message #11 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Wed, 10 Nov 2021 08:00:25 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks.
>
> It's a large patch, so let's start with the general, a.k.a. "big"
> aspects.
>
> First, do we really need to use *.cc files and compile with a C++
> compiler?  Is that a necessity?  AFAICT, the code in those *.cc files
> is plain C, so why not use a C compiler, as we do on every other
> platform?

That isn't C code.  The code in the .cc code is written in C++, in order
to use the Haiku GUI libraries which require C++.  I tried to keep it
simple and understandable for people who don't know C++, but know C.

That C++ code, in turn, exports functions the rest of Emacs uses as
`extern "C"'.

> Next, the font backend stuff: do we really need 5 (five) backends?
> How about having just one: HarfBuzz+Cairo?  That's the direction we go
> on other platforms, so how about making the Haiku code smaller and
> simpler and support just that single backend, and drop all the older
> ones?  I'd definitely won't want to drag the unmaintained libm17n-flt
> into this port.

I'm fine with removing the ftbe backend, but I would prefer to keep the
haikufont backend working.  The reason is that Haiku users might not
have Cairo installed, and it likes to break every now and then, as it's
not considered important for that platform.

> If you are okay with the above, could you please update the patch, so
> that we could avoid reviewing code which eventually won't be
> installed?

Yes, but please tell me if you're OK with keeping haikufont first.
Thanks.

Message #16 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Wed, 10 Nov 2021 12:33:31 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> I'm fine with removing the ftbe backend, but I would prefer to keep the
> haikufont backend working.  The reason is that Haiku users might not
> have Cairo installed, and it likes to break every now and then, as it's
> not considered important for that platform.

Actually, I now recall another problem with the Cairo font backend,
which is that it can't support color-mapped visuals.  This is a
limitation of how Cairo and Haiku define color mapping differently.

So I don't think it's good to remove ftbe anymore, either.  Thanks.

Message #19 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Wed, 10 Nov 2021 14:38:18 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Wed, 10 Nov 2021 08:00:25 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks.
> >
> > It's a large patch, so let's start with the general, a.k.a. "big"
> > aspects.
> >
> > First, do we really need to use *.cc files and compile with a C++
> > compiler?  Is that a necessity?  AFAICT, the code in those *.cc files
> > is plain C, so why not use a C compiler, as we do on every other
> > platform?
> 
> That isn't C code.  The code in the .cc code is written in C++, in order
> to use the Haiku GUI libraries which require C++.

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.

> > Next, the font backend stuff: do we really need 5 (five) backends?
> > How about having just one: HarfBuzz+Cairo?  That's the direction we go
> > on other platforms, so how about making the Haiku code smaller and
> > simpler and support just that single backend, and drop all the older
> > ones?  I'd definitely won't want to drag the unmaintained libm17n-flt
> > into this port.
> 
> I'm fine with removing the ftbe backend, but I would prefer to keep the
> haikufont backend working.  The reason is that Haiku users might not
> have Cairo installed, and it likes to break every now and then, as it's
> not considered important for that platform.

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

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

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.

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

Message #22 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Wed, 10 Nov 2021 20:56:10 +0800

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

Message #25 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Wed, 10 Nov 2021 16:19:49 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Wed, 10 Nov 2021 20:56:10 +0800
> 
> Eli Zaretskii <eliz <at> 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.

And for a good reason.  Then I think you should remove the part of
configure.ac that looks for other C++ compilers, as that is entirely
unnecessary, and probably will always be.

> > 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.

The other platforms have past history, which Haiku doesn't.  And we
plan on removing more old backends in the future; for example
Uniscribe for Windows will die soon enough because MS deprecated it,
and it is not being developed anymore, so falls behind in supporting
new scripts and features.

> 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.

OK, let's go with two.  I understand that both will use HarfBuzz?  I'd
prefer not to have backends that use other shaping engines, unless
Haiku has some shaping engine that is better than HarfBuzz.

> 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.

I hope you will reconsider.  Having a niche platform with 3 font
backends is really too much.  Especially since Emacs 29 learned to
display Emoji now, and we are talking about adding decent support for
ligatures, both of which require a shaping engine.

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

OK, please post an updated patch, and we'll take it from there.

Thanks.

Message #28 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Thu, 11 Nov 2021 08:27:18 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.
>
> And for a good reason.  Then I think you should remove the part of
> configure.ac that looks for other C++ compilers, as that is entirely
> unnecessary, and probably will always be.

Thanks, done.

> The other platforms have past history, which Haiku doesn't.  And we
> plan on removing more old backends in the future; for example
> Uniscribe for Windows will die soon enough because MS deprecated it,
> and it is not being developed anymore, so falls behind in supporting
> new scripts and features.

I understand now.  Thanks.

> OK, let's go with two.  I understand that both will use HarfBuzz?  I'd
> prefer not to have backends that use other shaping engines, unless
> Haiku has some shaping engine that is better than HarfBuzz.

The haikufont backend will use whatever shaping engine is used by the
App Server (the window server on Haiku).  Right now, it can't do any
fancy shaping, but the Haiku developers plan to add HarfBuzz in the
future.

Once that is done, then the haikufont backend will support HarfBuzz
without any further work.

> I hope you will reconsider.  Having a niche platform with 3 font
> backends is really too much.  Especially since Emacs 29 learned to
> display Emoji now, and we are talking about adding decent support for
> ligatures, both of which require a shaping engine.

OK, so WDYT about keeping haikufont and Cairo support?  Please let me
know, and I'll update the patch.  Thanks in advance!

Message #31 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Thu, 11 Nov 2021 08:51:25 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Thu, 11 Nov 2021 08:27:18 +0800
> 
> The haikufont backend will use whatever shaping engine is used by the
> App Server (the window server on Haiku).  Right now, it can't do any
> fancy shaping, but the Haiku developers plan to add HarfBuzz in the
> future.
> 
> Once that is done, then the haikufont backend will support HarfBuzz
> without any further work.
> 
> > I hope you will reconsider.  Having a niche platform with 3 font
> > backends is really too much.  Especially since Emacs 29 learned to
> > display Emoji now, and we are talking about adding decent support for
> > ligatures, both of which require a shaping engine.
> 
> OK, so WDYT about keeping haikufont and Cairo support?  Please let me
> know, and I'll update the patch.  Thanks in advance!

SGTM, thanks.

Message #34 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: 51658 <at> debbugs.gnu.org
>> Date: Thu, 11 Nov 2021 08:27:18 +0800
>> 
>> The haikufont backend will use whatever shaping engine is used by the
>> App Server (the window server on Haiku).  Right now, it can't do any
>> fancy shaping, but the Haiku developers plan to add HarfBuzz in the
>> future.
>> 
>> Once that is done, then the haikufont backend will support HarfBuzz
>> without any further work.
>> 
>> > I hope you will reconsider.  Having a niche platform with 3 font
>> > backends is really too much.  Especially since Emacs 29 learned to
>> > display Emoji now, and we are talking about adding decent support for
>> > ligatures, both of which require a shaping engine.
>> 
>> OK, so WDYT about keeping haikufont and Cairo support?  Please let me
>> know, and I'll update the patch.  Thanks in advance!
>
> SGTM, thanks.

Thanks.

Here is the updated commit message; the patch is attached.

Add support for the Haiku operating system and its window system 

* .gitignore: Add binaries specific to Haiku.

* Makefie.in (HAVE_BE_APP): New variable.
(install-arch-dep): Install Emacs and Emacs.pdmp when using Haiku.

* configure.ac: Detect and configure for Haiku and various related
 configurations.
(be-app, be-freetype, be-cairo): New options.
(HAVE_BE_APP, HAIKU_OBJ, HAIKU_CXX_OBJ)
(HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(HAIKU, HAVE_TINY_SPEED_T): New define.
(emacs_config_features): Add BE_APP.

* doc/emacs/Makefile.in (EMACSSOURCES): Add Haiku appendix.

* doc/emacs/emacs.texi: Add Haiku appendix to menus and
include it.

* doc/emacs/haiku.texi: New Haiku appendix.

* doc/lispref/display.texi (Defining Faces, Window Systems): Explain
haiku as a window system identifier.
(haiku-use-system-tooltips): Explain meaning of system tooltips on
Haiku.

* doc/lispref/frames.texi (Multiple Terminals): Explain meaning of
haiku as a display type.
(Frame Layout): Clarify section for Haiku frames.
(Size Parameters): Explain limitations of fullwidth and fullheight
on Haiku.
(Management Parameters): Explain limitations of inhibiting double
buffering on builds with Cairo, and the inability of frames with
no-accept-focus to receive keyboard input on Haiku.
(Font and Color Parameters): Explain the different font backends
available on Haiku.
(Raising and Lowering): Explain that lowering and restacking frames
doesn't work on Haiku.
(Child Frames): Explain oddities of child frame visibility on Haiku.

* doc/lispref/os.texi (System Environment): Explain meaning of haiku
.
* etc/MACHINES: Add appropriate notices for Haiku.
* etc/NEWS: Document changes.
* etc/PROBLEMS: Document font spacing bug on Haiku.

* lib-src/Makefile.in: Build be-resources binary on Haiku.
(CXX, CXXFLAGS, NON_CXX_FLAGS, ALL_CXXFLAGS)
(HAVE_BE_APP, HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(DONT_INSTALL): Add be-resources binary if on Haiku.
(be-resources): New target.

* lib-src/be_resources: Add helper binary for setting resources on
the Emacs application.

* lib-src/emacsclient.c (decode_options): Set alt_display to "be"
on Haiku.

* lisp/cus-edit.el (custom-button, custom-button-mouse)
(custom-button-unraised, custom-button-pressed): Update face
definitions for Haiku.

* lisp/cus-start.el: Add haiku-debug-on-fatal-error and
haiku-use-system-tooltips.

* lisp/faces.el (face-valid-attribute-values): Clarify attribute
comment for Haiku.
(tool-bar): Add appropriate toolbar color for Haiku.

* lisp/frame.el (haiku-frame-geometry)
(haiku-mouse-absolute-pixel-position)
(haiku-set-mouse-absolute-pixel-position)
(haiku-frame-edges)
(haiku-frame-list-z-order): New function declarations.

(frame-geometry, frame-edges)
(mouse-absolute-pixel-position)
(set-mouse-absolute-pixel-position)
(frame-list-z-order): Call appropriate window system functions
on Haiku.

(display-mouse-p, display-graphic-p)
(display-images-p, display-pixel-height)
(display-pixel-width, display-mm-height)
(display-mm-width, display-backing-store)
(display-save-under, display-planes)
(display-color-cells, display-visual-class): Update type tests
for Haiku.

* lisp/international/mule-cmds.el (set-coding-system-map): Also
prevent set-terminal-coding-system from appearing in the menu bar
on Haiku.

* lisp/loadup.el: Load Haiku-specific files when built with Haiku,
and don't rename newly built Emacs on Haiku as BFS doesn't support
hard links.

* lisp/menu-bar.el (menu-bar-open): Add for Haiku.

* lisp/mwheel.el (mouse-wheel-down-event): Expect wheel-up on Haiku.
(mouse-wheel-up-event): Expect wheel-down on Haiku.
(mouse-wheel-left-event): Expect wheel-left on Haiku.
(mouse-wheel-right-event): Expect wheel-right on Haiku.

* lisp/net/browse-url.el (browse-url--browser-defcustom-type):
Add option for WebPositive.
(browse-url-webpositive-program): New variable.
(browse-url-default-program): Search for WebPositive.
(browse-url-webpositive): New function.

* lisp/net/eww.el (eww-form-submit, eww-form-file)
(eww-form-checkbox, eww-form-select): Define faces appropriately
for Haiku.

* lisp/term/haiku-win.el: New file.

* lisp/tooltip.el (menu-or-popup-active-p): New function declaration.
(tooltip-show-help): Don't use tooltips on Haiku when a menu is active.

* lisp/version.el (haiku-get-version-string): New function declaration.
(emacs-version): Add Haiku version string if appropriate.

* src/Makefile.in: Also produce binary named "Emacs" with Haiku resources
set.

(CXX, HAIKU_OBJ, HAIKU_CXX_OBJ, HAIKU_LIBS)
(HAIKU_CFLAGS, HAVE_BE_APP, NON_CXX_FLAGS, ALL_CXX_FLAGS): New
variables.

(.SUFFIXES): Add .cc.
(.cc.o): New target.
(base_obj): Add Haiku C objects.
(doc_obj, obj): Split objects that should scanned for documentation
into doc_obj.
(SOME_MACHINE_OBJECTS): Add appropriate Haiku C objects.
(all): Depend on Emacs and Emacs.pdmp on Haiku.
(LIBES): Add Haiku libraries.
(gl-stamp)
($(etc)/DOC): Scan doc_obj instead of obj
(temacs$(EXEEXT): Use C++ linker on Haiku.
(ctagsfiles3): New variable.
(TAGS): Scan C++ files.

* src/alloc.c (garbage_collect): Mark Haiku display.

* src/dispextern.h (HAVE_NATIVE_TRANSFORMS): Also enable on Haiku.
(struct image): Add fields for Haiku transforms.
(RGB_PIXEL_COLOR): Define to unsigned long on Haiku as well.
(sit_for): Also check USABLE_SIGPOLL.
(init_display_interactive): Set initial window system to Haiku on
Haiku builds.

* src/emacs.c (main): Define Haiku syms and init haiku clipboard.
(shut_down_emacs): Quit BApplication on Haiku and trigger debug
on aborts if haiku_debug_on_fatal_error.
(Vsystem_type): Update docstring.

* src/fileio.c (next-read-file-uses-dialog-p): Enable on Haiku.

* src/filelock.c (WTMP_FILE): Only define if BOOT_TIME is also
defined.

* src/floatfns.c (double_integer_scale): Work around Haiku libroot
brain damage.

* src/font.c (syms_of_font): Define appropriate font driver symbols
for Haiku builds with various options.

* src/font.h: Also enable ftcrfont on Haiku builds with Cairo.
(font_data_structures_may_be_ill_formed): Also enable on Haiku
builds that have FreeType or Cairo.

* src/frame.c (Fframep): Update doc-string for Haiku builds and
return haiku if appropriate.
(syms_of_frame): New symbol `haiku'.

* src/frame.h (struct frame): Add output data for Haiku.
(FRAME_HAIKU_P): New macro.
(FRAME_WINDOW_P): Test for Haiku frames as well.

* src/ftcrfont.c (RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG): New macros.
(ftcrfont_draw): Add haiku specific code for Haiku builds with Cairo.

* src/ftfont.c (ftfont_open): Set face.
(ftfont_has_char, ftfont_text_extents): Work around crash.
(syms_of_ftfont): New symbol `mono'.

* src/ftfont.h (struct font_info): Enable Cairo-specific fields for Cairo
builds on Haiku.

* src/haiku_draw_support.cc:
* src/haiku_font_support.cc:
* src/haiku_io.c:
* src/haiku_select.cc:
* src/haiku_support.cc:
* src/haiku_support.h:
* src/haikufns.c:
* src/haikufont.c:
* src/haikugui.h:
* src/haikuimage.c:
* src/haikumenu.c:
* src/haikuselect.c:
* src/haikuselect.h:
* src/haikuterm.c:
* src/haikuterm.h: Add new files for Haiku windowing support.

* src/image.c: Implement image transforms and native XPM support
on Haiku.

(GET_PIXEL, PUT_PIXEL, NO_PIXMAP)
(PIX_MASK_RETAIN, PIX_MASK_DRAW)
(RGB_TO_ULONG, RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG, RED16_FROM_ULONG, GREEN16_FROM_ULONG)
(BLUE16_FROM_ULONG): Define to appropriate values on Haiku.

(image_create_bitmap_from_data): Add Haiku support.
(image_create_bitmap_from_file): Add TODO on Haiku.
(free_bitmap_record): Free bitmap on Haiku.
(image_size_in_bytes): Implement for Haiku bitmaps.
(image_set_transform): Implement on Haiku.
(image_create_x_image_and_pixmap_1): Implement on Haiku, 24-bit or
1-bit only.
(image_destroy_x_image, image_get_x_image): Use correct img and
pixmap values on Haiku.
(lookup_rgb_color): Use correct macro on Haiku.
(image_to_emacs_colors): Implement on Haiku.
(image_disable_image): Disable on Haiku.
(image_can_use_native_api): Test for translator presence on Haiku.
(native_image_load): Use translator on Haiku.
(imagemagick_load_image): Add Haiku-specific quirks.
(Fimage_transforms_p): Allow rotate90 on Haiku.
(image_types): Enable native XPM support on Haiku.
(syms_of_image): Enable XPM images on Haiku.

* src/keyboard.c (kbd_buffer_get_event)
(handle_async_input, handle_input_available_signal)
(handle_user_signal, Fset_input_interrupt_mode)
(init_keyboard): Check for USABLE_SIGPOLL along with USABLE_SIGIO.

(make_lispy_event, kbd_buffer_get_event)
(syms_of_keyboard): Handle special Haiku events.

* src/lisp.h (pD): Work around broken Haiku headers.
(HAVE_EXT_MENU_BAR): Define on Haiku.
(handle_input_available_signal): Enable if we just have SIGPOLL
as well.

* src/menu.c (have_boxes): Return true on Haiku.
(single_menu_item): Enable toolkit menus on Haiku.
(find_and_call_menu_selection): Also enable on Haiku.

* src/process.c (keyboard_bit_set): Enable with only usable SIGPOLL.
(wait_reading_process_output): Test for SIGPOLL as well as SIGIO
availability.

* src/sound.c (sound_perror, vox_open)
(vox_configure, vox_close): Enable for usable SIGPOLL as well.

* src/sysdep.c (sys_subshell): Enable for usable SIGPOLL.
(reset_sigio): Make conditional on F_SETOWN.
(request_sigio, unrequest_sigio)
(emacs_sigaction_init): Also handle SIGPOLLs.
(init_sys_modes): Disable TCXONC usage on Haiku, as it doesn't
have any ttys other than pseudo ttys, which don't support C-s/C-q
flow control.
(speeds): Disable high speeds if HAVE_TINY_SPEED_T.
(list_system_processes, system_process_attributes): Implement for
Haiku.

* src/termhooks.h (enum output_method): Add output_haiku.
(enum event_kind): Add HAIKU_REFS_FOUND_EVENT and
HAIKU_QUIT_REQUESTED_EVENT.
(struct terminal): Add Haiku display info.
(TERMINAL_FONT_CACHE): Enable for Haiku.

* src/terminal.c (Fterminal_live_p): Return `haiku' if appropriate.
* src/verbose.mk.in (AM_V_CXX, AM_V_CXXLD): New logging variables.

* src/xdisp.c (redisplay_internal, note_mouse_highlight): Return on
Haiku if a popup is activated.
(display_menu_bar): Return on Haiku if frame is a Haiku frame.

* src/xfaces.c (GCGraphicsExposures): Enable correctly on Haiku.
(x_create_gc): Enable dummy GC code on Haiku.

* src/xfns.c (x-server-version, x-file-dialog): Add Haiku specifics
to doc strings.

* src/xterm.c (syms_of_xterm): Add Haiku information to doc string.

[haiku-emacs.patch (text/x-patch, attachment)]

Message #37 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 13 Nov 2021 20:31:12 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Thu, 11 Nov 2021 15:40:01 +0800
> 
> Here is the updated commit message; the patch is attached.

See the comments below.

> +  HAVE_M17N_FLT=no
> +  if test "${HAVE_LIBOTF}" = yes; then
> +    if test "${with_m17n_flt}" != "no"; then
> +      EMACS_CHECK_MODULES([M17N_FLT], [m17n-flt])
> +      if test "$HAVE_M17N_FLT" = "yes"; then
> +	AC_DEFINE(HAVE_M17N_FLT, 1, [Define to 1 if using libm17n-flt.])
> +      fi
> +    fi
> +  fi

Do we need libm17n-flt?  For which font back-end is it needed?

> +@cindex TTY Emacs in haiku

@cindex entries should begin from a lower-case letter, so that they
sort predictably regardless of the locale where the manual is built.

> +  If you are launching Emacs from the Tracker, or want to make the
> +Tracker open files using Emacs, you should use the binary named
> +@code{Emacs}; If you are going to use Emacs in the terminal, or wish
                 ^^
Should be "if", not capitalized.

> +to launch separate instances of Emacs, or do not care for the
> +aforementioned system integration features, the binary named

What "system integration features" does this text refer to?  It's
unclear from the text.

> +@code{emacs} should be used instead.
                ^^^^^^^^^^^^^^
Passive tense!

> +  On Haiku, unusual modifier keys such as the Hyper key are
> +unsupported.  By default, the super key corresponds with the option
> +key defined by the operating system, the meta key with the command
> +key, the control key with the system control key, and the shift key
> +with the system shift key.  On a standard PC keyboard, Haiku should
> +map these keys to positions familiar to those using a GNU system, but
> +this may require some adjustment to your system's configuration to
> +work.

This sounds no different from any other system, so I wonder why this
needs to be described.  On most systems, there's no Super or Hyper
keys, and they can be simulated via "C-x @", unless the user
configures the keyboard to do some remapping.

> +  If the system shift key is held down, Emacs will always use the
> +system shift keymap regardless of what other modifier keys are
> +currently held down.  Otherwise, if any other modifier key is held
> +down, the default system keymap will be used to map keys.  This makes
> +it impossible to type accented characters using the system super key
> +map.

This description focuses on the underlying technical issue, and leaves
the user-facing behavior not sufficiently clear.  This is a user
manual, so it is best to describe the behavior users will see, and
leave out the technical details.  It sounds like all you want to say
is that accented letters cannot be typed using the super key? then
just say that without going int the details too much.

> +@cindex haiku input methods
> +@cindex BeCJK and Emacs
> +  Some popular Haiku input methods such BeCJK are known to behave
> +badly when interacting with Emacs.  If you are affected, you can use
> +an Emacs input method instead.  See @ref{Input Methods}.

This should be in PROBLEMS, not here.

> +  On Haiku, Emacs defaults to using the system tooltip mechanism.
> +This usually leads to more responsive tooltips, but the tooltips will
> +not be able to use advanced display features.  If that is what you
> +need, you can disable the use of system tooltips by setting the
> +variable @code{haiku-use-system-tooltips} to nil. (@pxref{Tooltips,,,
> +elisp, The Emacs Lisp Reference Manual}).

How is this different from the GTK build?  If it isn't different,
maybe it shouldn't be mentioned at all.

> +@subsection What to do when Emacs crashes
> +@cindex haiku debugger
> +@vindex haiku-debug-on-fatal-error

This should have an index entry starting from "crashes", so that users
could find it easily.

> +@node Haiku Customization
> +@section Customizations specific to Haiku
> +  This section details several customizations that are specific to
> +Haiku windowing.
> +
> +@table @code
> +@vindex haiku-use-system-tooltips
> +@item haiku-use-system-tooltips
> +This variable controls whether or not system tooltips will be used.
> +
> +When non-nil, tooltips are displayed by the Application Kit and not
> +Emacs, and accordingly do not have a tooltip frame.  As such, they are
> +also unable to utilize any display properties.
> +
> +@vindex haiku-use-system-debugger
> +@item haiku-use-system-debugger
> +When non-nil, Emacs will ask the system to launch the system debugger
> +whenever it experiences a fatal error.  This behaviour is standard
> +among Haiku applications.
> +@end table

These descriptions should be in the same place where the corresponding
behaviors are described.  Having them in a separate section makes them
harder to discover.

> +@subsection Modifier keys
> +@cindex modifier key customization (Haiku)
> +You can customize which Emacs modifiers the various system modifier
> +keys correspond to through the following variables:
> +
> +@table @code
> +@vindex haiku-meta-keysym
> +@item haiku-meta-keysym
> +The system modifier key that will be treated as the Meta key by Emacs.
> +It defaults to @code{command}.
> +
> +@vindex haiku-control-keysym
> +@item haiku-control-keysym
> +The system modifier key that will be treated as the Control key by
> +Emacs.  It defaults to @code{control}.
> +
> +@vindex haiku-super-keysym
> +@item haiku-super-keysym
> +The system modifier key that will be treated as the Super key by
> +Emacs.  It defaults to @code{option}.

These should be in the same section that describes the keyboard
peculiarities.

> +@vindex haiku-shift-keysym
> +@item haiku-super-keysym
               ^^^^^
Copy/paste error?

> +@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.

> +@item haiku-quit-requested
> +This event is received whenever the operating system tells Emacs that
> +the user has asked Emacs to quit, optionally seeking confirmation if
> +the user has any unsaved documents. By default, it is bound to
> +@code{save-buffers-kill-emacs}, see @ref{Exiting}.

And this should be connected to the session manager, see xsmfns.c, and
then it can just trigger the mechanism defined there, as on other
platforms.

> +@node Haiku Resources
> +@section Using the X defaults database on Haiku
> +@cindex X resources, haiku
> +@cindex x-get-resource, haiku
> +
> +  As there is no equivalent to an X resource database on Haiku, a
> +facsimile is provided in its place.  This facsimile does not attempt
> +to process X resource files, but is responsive to the @kbd{--xrm}
> +command-line argument.  For details about using this argument, see
> +@ref{Resources}.

"Resources" is a general section, unrelated to Haiku.  If there's
nothing special we must say about resources on Haiku, why do we need
this section?

> +@node Haiku Fonts
> +@section Font and font backend selection on Haiku
> +@cindex font backend selection (Haiku)

This should be reworded to say that Haiku uses 2 font backends used by
other platforms, and has one Haiku-specific backend.  There's no
reason to describe the backends that are named the same as their
GNU/Linux counterparts, except if their behavior significantly
differs.

> +  The @code{ftcr} font backend is available whenever Emacs is built
> +with Cairo support.  It is the most fully featured, but will cause
> +display issues when used on a frame with double-buffering disabled.

The right place for this is in PROBLEMS again.

> +  This font backend has a known problem with displaying certain bold
> +or italic fonts on older Haiku systems.  It is documented in
> +@file{etc/PROBLEMS}, see @ref{Known Problems}.

No need to repeat this in the manual.

> +  The @code{ftcr} backend features HarfBuzz variants when Emacs is
               ^^^^
Typo (but I see no reason to have this part in the manual, see above).

> @@ -8250,6 +8254,12 @@ Tooltips
>  @code{nil}.  The rest of this subsection describes how to control
>  non-GTK+ tooltips, which are presented by Emacs itself.
>  
> +@vindex haiku-use-system-tooltips
> +When Emacs is built with the Haiku Application Kit, it usually displays
> +tooltips using Application Kit functions.  When using these tooltips, text
> +properties inside tooltip text will be unavailable. To disable these
> +tooltips, change the value of @code{haiku-use-system-tooltips} to @code{nil}.

It is not a good idea to have the same feature described in more than
one place: it leads to inconsistencies, and is generally a maintenance
burden.  Decide whether you want to describe this here or in the Haiku
appendix, and either have the description in that one place, or leave
only the cross-reference in the other with minimum text.  And make
sure the index entry leads to the place with the actual description,
not to the place where you have a cross-reference.

> +On Haiku, setting @code{fullscreen} to @code{fullwidth} or
> +@code{fullheight} has no effect.

This is not important enough to be in the text; please make it a
@footnote.

> +If Emacs is built with Haiku and Cairo, inhibiting double buffering on
> +a frame may lead to severe artifacting when display elements such as
> +the mouse cursor pass over a frame.

This sounds like stuff for PROBLEMS again.

> @@ -2191,7 +2199,8 @@ Management Parameters
>  @code{mouse-autoselect-window} (@pxref{Mouse Window Auto-selection}).
>  This may have the unwanted side-effect that a user cannot scroll a
>  non-selected frame with the mouse.  Some window managers may not honor
> -this parameter.
> +this parameter.  On Haiku, it also has the side-effect that the window
> +will not be able to receive any keyboard input from the user.

I don't understand: non-selected windows don't receive keyboard input
on all systems.  So what is special about Haiku here?

> @@ -2352,7 +2361,13 @@ Font and Color Parameters
>  engine), and @code{harfbuzz} (font driver for OTF and TTF fonts with
>  HarfBuzz text shaping) (@pxref{Windows Fonts,,, emacs, The GNU Emacs
>  Manual}).  The @code{harfbuzz} driver is similarly recommended.  On
> -other systems, there is only one available font backend, so it does
> +Haiku, there are up to two font drivers: @code{haiku} (the server-side
> +font driver, always available), and @code{ftcr} (a font-driver using
> +Cairo, only available if Emacs was built with Cairo).  For
> +@code{ftcr}, there also exists a variant that shapes text using
> +HarfBuzz, named @code{ftcrhb}.

This is an unnecessary repetition of what you already say in the
appendix.

> +Lowering frames is not supported on Haiku, due to limitations imposed
> +by the system.

This should also be in a @footnote.

> +Restacking frames is not supported on Haiku, due to limitations
> +imposed by the system.

And this.

> +  On Haiku, child frames are only visible when a parent frame is
> +active, owing to a limitation of the Haiku windowing system.  Owing to
> +the same limitation, child frames are only guaranteed to appear above
> +their top-level parent; that is to say, the top-most frame in the
> +hierarchy, which does not have a parent frame.

And this.

> +** Emacs has been ported to the Haiku operating system.
> +The configuration process should automatically detect and build for Haiku.
> +There is also an optional window-system port to Haiku, which can be enabled
> +by configuring Emacs with the option '--with-be-app', which will require
> +the Haiku Application Kit development headers and a C++ compiler to be present
> +on your system.  If Emacs is not built with the option '--with-be-app', the
> +resulting Emacs will only run in text-mode terminals.
> +
> ++++
> +** Cairo drawing support has been enabled for Haiku builds.
> +To enable Cairo support, ensure that the Cairo and FreeType development files
> +are present on your system, and configure Emacs with '--with-be-cairo'.
> +
> +---
> +** Double buffering is now enabled on the Haiku operating system.
> +Unlike X, there is no compile-time option to enable or disable double-buffering.
> +If you wish to disable double-buffering, change the frame parameter
> +`inhibit-double-buffering' instead.
> +

This should be a single "**" parent entry with "***" sub-entries.

> --- a/lisp/loadup.el
> +++ b/lisp/loadup.el
> @@ -302,6 +302,13 @@
>        (load "term/common-win")
>        (load "term/x-win")))
>  
> +(if (featurep 'haiku)
> +    (progn
> +      (load "term/common-win")
> +      (load "term/haiku-win")
> +      (load "international/mule-util")
> +      (load "international/ucs-normalize")))

Why do you need ucs-normalize?  And what about the condition not to
load it if uni-*.el files are unavailable?

> --- a/src/floatfns.c
> +++ b/src/floatfns.c
> @@ -347,6 +347,19 @@ DEFUN ("logb", Flogb, Slogb, 1, 1, 0,
>  double_integer_scale (double d)
>  {
>    int exponent = ilogb (d);
> +#ifdef HAIKU
> +  /* On Haiku, the values of FP_ILOGB0 and FP_ILOGBNAN are identical.
> +     To top it all, both are also identical to INT_MAX.  */
> +  if (exponent == FP_ILOGB0)
> +    {
> +      if (isnan (d))
> +	return (DBL_MANT_DIG - DBL_MIN_EXP) + 2;
> +      if (isinf (d))
> +	return (DBL_MANT_DIG - DBL_MIN_EXP) + 1;
> +
> +      return (DBL_MANT_DIG - DBL_MIN_EXP);
> +    }
> +#endif

I don't understand what the situation with FP_ILOGB0 has to do with
logb function's implementation and the workaround you add here.
Please clarify the comment.

> -#ifdef USE_CAIRO
> +#if defined (USE_CAIRO) || defined (USE_BE_CAIRO)

Does this mean that USE_CAIRO code is not used by Haiku when Emacs is
built with Cairo on Haiku?  Why is that?  And why cannot Haiku use
USE_CAIRO?

> diff --git a/src/haiku_draw_support.cc b/src/haiku_draw_support.cc
> new file mode 100644
> index 0000000000..c04bed81c2
> --- /dev/null
> +++ b/src/haiku_draw_support.cc

There isn't a single comment in this and other Haiku-specific source
files.  Please consider adding at least comments describing what the
important non-trivial functions do and what their arguments mean.

Btw, many comments in source files that are similar to X and w32 seem
to have been copied wholesale from those other systems.  I have no way
of verifying whether the copied comments are accurate for Haiku, so
it's up to you to audit them.

> +/* 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.  */};

Why not use script-representative-chars here?

> +_Noreturn void
> +gui_abort (const char *msg)
> +{
> +  fprintf (stderr, "Abort in GUI code: %s\n", msg);
> +  fprintf (stderr, "Under Haiku, Emacs cannot recover from errors in GUI code\n");
> +  fprintf (stderr, "App Server disconnects usually manifest as bitmap "
> +	   "initialization failures or lock failures.");
> +  emacs_abort ();
> +}

Are these writes to stderr going to stay in the production code?

> +	key = strdup (ky);
> +	if (!key)
> +	  {
> +	    perror ("strdup");
> +	    gui_abort ("strdup failed");
> +	  }
> +      }
> +
> +    if (help)
> +      {
> +	this->help = strdup (help);
> +	if (!this->help)
> +	  {
> +	    perror ("strdup");
> +	    gui_abort ("strdup failed");
> +	  }
> +      }

And these calls to perror?

> -#ifdef HAVE_EXT_MENU_BAR
> +#if defined (HAVE_EXT_MENU_BAR) || defined (HAVE_HAIKU)

Why is this needed?  You did define HAVE_EXT_MENU_BAR on Haiku, right?

> @@ -3119,6 +3143,23 @@ list_system_processes (void)
>    return  proclist;
>  }
>  
> +#elif defined HAIKU
> +
> +Lisp_Object
> +list_system_processes (void)
> +{

Can the Haiku-specific bits here be moved to some Haiku-specific file?

Thanks.

Message #40 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> See the comments below.

>> +  HAVE_M17N_FLT=no
>> +  if test "${HAVE_LIBOTF}" = yes; then
>> +    if test "${with_m17n_flt}" != "no"; then
>> +      EMACS_CHECK_MODULES([M17N_FLT], [m17n-flt])
>> +      if test "$HAVE_M17N_FLT" = "yes"; then
>> +	AC_DEFINE(HAVE_M17N_FLT, 1, [Define to 1 if using libm17n-flt.])
>> +      fi
>> +    fi
>> +  fi

> Do we need libm17n-flt?  For which font back-end is it needed?

The Cairo font backend has the ability to use libm17n-flt.  The code for
that is in ftcrfont.c, as it is on X-Windows.

>> +@cindex TTY Emacs in haiku

> @cindex entries should begin from a lower-case letter, so that they
> sort predictably regardless of the locale where the manual is built.

Thanks, fixed.

>> +  If you are launching Emacs from the Tracker, or want to make the
>> +Tracker open files using Emacs, you should use the binary named
>> +@code{Emacs}; If you are going to use Emacs in the terminal, or wish
>                  ^^
> Should be "if", not capitalized.
>
>> +to launch separate instances of Emacs, or do not care for the
>> +aforementioned system integration features, the binary named
>
> What "system integration features" does this text refer to?  It's
> unclear from the text.
>
>> +@code{emacs} should be used instead.
>                 ^^^^^^^^^^^^^^
> Passive tense!

>> +  On Haiku, unusual modifier keys such as the Hyper key are
>> +unsupported.  By default, the super key corresponds with the option
>> +key defined by the operating system, the meta key with the command
>> +key, the control key with the system control key, and the shift key
>> +with the system shift key.  On a standard PC keyboard, Haiku should
>> +map these keys to positions familiar to those using a GNU system, but
>> +this may require some adjustment to your system's configuration to
>> +work.

> This sounds no different from any other system, so I wonder why this
> needs to be described.  On most systems, there's no Super or Hyper
> keys, and they can be simulated via "C-x @", unless the user
> configures the keyboard to do some remapping.

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

>> +  If the system shift key is held down, Emacs will always use the
>> +system shift keymap regardless of what other modifier keys are
>> +currently held down.  Otherwise, if any other modifier key is held
>> +down, the default system keymap will be used to map keys.  This makes
>> +it impossible to type accented characters using the system super key
>> +map.

> This description focuses on the underlying technical issue, and leaves
> the user-facing behavior not sufficiently clear.  This is a user
> manual, so it is best to describe the behavior users will see, and
> leave out the technical details.  It sounds like all you want to say
> is that accented letters cannot be typed using the super key? then
> just say that without going int the details too much.

Okay, thanks.

>> +@cindex haiku input methods
>> +@cindex BeCJK and Emacs
>> +  Some popular Haiku input methods such BeCJK are known to behave
>> +badly when interacting with Emacs.  If you are affected, you can use
>> +an Emacs input method instead.  See @ref{Input Methods}.

> This should be in PROBLEMS, not here.

Done, thanks.

>> +  On Haiku, Emacs defaults to using the system tooltip mechanism.
>> +This usually leads to more responsive tooltips, but the tooltips will
>> +not be able to use advanced display features.  If that is what you
>> +need, you can disable the use of system tooltips by setting the
>> +variable @code{haiku-use-system-tooltips} to nil. (@pxref{Tooltips,,,
>> +elisp, The Emacs Lisp Reference Manual}).

> How is this different from the GTK build?  If it isn't different,
> maybe it shouldn't be mentioned at all.

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

>> +@subsection What to do when Emacs crashes
>> +@cindex haiku debugger
>> +@vindex haiku-debug-on-fatal-error

> This should have an index entry starting from "crashes", so that users
> could find it easily.

>> +@node Haiku Customization
>> +@section Customizations specific to Haiku
>> +  This section details several customizations that are specific to
>> +Haiku windowing.
>> +
>> +@table @code
>> +@vindex haiku-use-system-tooltips
>> +@item haiku-use-system-tooltips
>> +This variable controls whether or not system tooltips will be used.
>> +
>> +When non-nil, tooltips are displayed by the Application Kit and not
>> +Emacs, and accordingly do not have a tooltip frame.  As such, they are
>> +also unable to utilize any display properties.
>> +
>> +@vindex haiku-use-system-debugger
>> +@item haiku-use-system-debugger
>> +When non-nil, Emacs will ask the system to launch the system debugger
>> +whenever it experiences a fatal error.  This behaviour is standard
>> +among Haiku applications.
>> +@end table
>> +@subsection Modifier keys
>> +@cindex modifier key customization (Haiku)
>> +You can customize which Emacs modifiers the various system modifier
>> +keys correspond to through the following variables:
>> +
>> +@table @code
>> +@vindex haiku-meta-keysym
>> +@item haiku-meta-keysym
>> +The system modifier key that will be treated as the Meta key by Emacs.
>> +It defaults to @code{command}.
>> +
>> +@vindex haiku-control-keysym
>> +@item haiku-control-keysym
>> +The system modifier key that will be treated as the Control key by
>> +Emacs.  It defaults to @code{control}.
>> +
>> +@vindex haiku-super-keysym
>> +@item haiku-super-keysym
>> +The system modifier key that will be treated as the Super key by
>> +Emacs.  It defaults to @code{option}.

> These should be in the same section that describes the keyboard
> peculiarities.

Thanks.

>> +@vindex haiku-shift-keysym
>> +@item haiku-super-keysym
>                ^^^^^
> Copy/paste error?

Good catch, thanks.

>> +@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.

>> +@item haiku-quit-requested
>> +This event is received whenever the operating system tells Emacs that
>> +the user has asked Emacs to quit, optionally seeking confirmation if
>> +the user has any unsaved documents. By default, it is bound to
>> +@code{save-buffers-kill-emacs}, see @ref{Exiting}.

> And this should be connected to the session manager, see xsmfns.c, and
> then it can just trigger the mechanism defined there, as on other
> platforms.

Isn't the mechanism there specific to X?  I could not find an example of
any other port using it, and it seems to use X specific functions.

>> +@node Haiku Resources
>> +@section Using the X defaults database on Haiku
>> +@cindex X resources, haiku
>> +@cindex x-get-resource, haiku
>> +
>> +  As there is no equivalent to an X resource database on Haiku, a
>> +facsimile is provided in its place.  This facsimile does not attempt
>> +to process X resource files, but is responsive to the @kbd{--xrm}
>> +command-line argument.  For details about using this argument, see
>> +@ref{Resources}.

> "Resources" is a general section, unrelated to Haiku.  If there's
> nothing special we must say about resources on Haiku, why do we need
> this section?

Makes sense, I deleted it, thanks.

>> +@node Haiku Fonts
>> +@section Font and font backend selection on Haiku
>> +@cindex font backend selection (Haiku)

> This should be reworded to say that Haiku uses 2 font backends used by
> other platforms, and has one Haiku-specific backend.  There's no
> reason to describe the backends that are named the same as their
> GNU/Linux counterparts, except if their behavior significantly
> differs.

>> +  The @code{ftcr} font backend is available whenever Emacs is built
>> +with Cairo support.  It is the most fully featured, but will cause
>> +display issues when used on a frame with double-buffering disabled.
>
> The right place for this is in PROBLEMS again.

Thanks.

>> +  This font backend has a known problem with displaying certain bold
>> +or italic fonts on older Haiku systems.  It is documented in
>> +@file{etc/PROBLEMS}, see @ref{Known Problems}.

> No need to repeat this in the manual.

Thanks.

>> @@ -8250,6 +8254,12 @@ Tooltips
>>  @code{nil}.  The rest of this subsection describes how to control
>>  non-GTK+ tooltips, which are presented by Emacs itself.
>>  
>> +@vindex haiku-use-system-tooltips
>> +When Emacs is built with the Haiku Application Kit, it usually displays
>> +tooltips using Application Kit functions.  When using these tooltips, text
>> +properties inside tooltip text will be unavailable. To disable these
>> +tooltips, change the value of @code{haiku-use-system-tooltips} to @code{nil}.

> It is not a good idea to have the same feature described in more than
> one place: it leads to inconsistencies, and is generally a maintenance
> burden.  Decide whether you want to describe this here or in the Haiku
> appendix, and either have the description in that one place, or leave
> only the cross-reference in the other with minimum text.  And make
> sure the index entry leads to the place with the actual description,
> not to the place where you have a cross-reference.

Understood, that entry seems to be entirely redundant, so it has been
deleted.

>> +On Haiku, setting @code{fullscreen} to @code{fullwidth} or
>> +@code{fullheight} has no effect.
>
> This is not important enough to be in the text; please make it a
> @footnote.

Thanks, I did that.

> This sounds like stuff for PROBLEMS again.

Thanks.

>> @@ -2191,7 +2199,8 @@ Management Parameters
>>  @code{mouse-autoselect-window} (@pxref{Mouse Window Auto-selection}).
>>  This may have the unwanted side-effect that a user cannot scroll a
>>  non-selected frame with the mouse.  Some window managers may not honor
>> -this parameter.
>> +this parameter.  On Haiku, it also has the side-effect that the window
>> +will not be able to receive any keyboard input from the user.

> I don't understand: non-selected windows don't receive keyboard input
> on all systems.  So what is special about Haiku here?

`no-accept-focus' means that the frame isn't willing to accept focus
from mouse clicks and other mouse motion events.

On X-Windows, for instance, it is possible to give the keyboard focus to
such a frame by hitting Alt-TAB (in most window managers); this is not
possible on Haiku.

>> @@ -2352,7 +2361,13 @@ Font and Color Parameters
>>  engine), and @code{harfbuzz} (font driver for OTF and TTF fonts with
>>  HarfBuzz text shaping) (@pxref{Windows Fonts,,, emacs, The GNU Emacs
>>  Manual}).  The @code{harfbuzz} driver is similarly recommended.  On
>> -other systems, there is only one available font backend, so it does
>> +Haiku, there are up to two font drivers: @code{haiku} (the server-side
>> +font driver, always available), and @code{ftcr} (a font-driver using
>> +Cairo, only available if Emacs was built with Cairo).  For
>> +@code{ftcr}, there also exists a variant that shapes text using
>> +HarfBuzz, named @code{ftcrhb}.

> This is an unnecessary repetition of what you already say in the
> appendix.

Thanks, I replaced it with a reference.

>> +Lowering frames is not supported on Haiku, due to limitations imposed
>> +by the system.
>
> This should also be in a @footnote.
>
>> +Restacking frames is not supported on Haiku, due to limitations
>> +imposed by the system.
>
> And this.
>
>> +  On Haiku, child frames are only visible when a parent frame is
>> +active, owing to a limitation of the Haiku windowing system.  Owing to
>> +the same limitation, child frames are only guaranteed to appear above
>> +their top-level parent; that is to say, the top-most frame in the
>> +hierarchy, which does not have a parent frame.
>
> And this.
>
>> +** Emacs has been ported to the Haiku operating system.
>> +The configuration process should automatically detect and build for Haiku.
>> +There is also an optional window-system port to Haiku, which can be enabled
>> +by configuring Emacs with the option '--with-be-app', which will require
>> +the Haiku Application Kit development headers and a C++ compiler to be present
>> +on your system.  If Emacs is not built with the option '--with-be-app', the
>> +resulting Emacs will only run in text-mode terminals.
>> +
>> ++++
>> +** Cairo drawing support has been enabled for Haiku builds.
>> +To enable Cairo support, ensure that the Cairo and FreeType development files
>> +are present on your system, and configure Emacs with '--with-be-cairo'.
>> +
>> +---
>> +** Double buffering is now enabled on the Haiku operating system.
>> +Unlike X, there is no compile-time option to enable or disable double-buffering.
>> +If you wish to disable double-buffering, change the frame parameter
>> +`inhibit-double-buffering' instead.
>> +
>
> This should be a single "**" parent entry with "***" sub-entries.

Thanks, all done.

>> --- a/lisp/loadup.el
>> +++ b/lisp/loadup.el
>> @@ -302,6 +302,13 @@
>>        (load "term/common-win")
>>        (load "term/x-win")))
>>  
>> +(if (featurep 'haiku)
>> +    (progn
>> +      (load "term/common-win")
>> +      (load "term/haiku-win")
>> +      (load "international/mule-util")
>> +      (load "international/ucs-normalize")))

> Why do you need ucs-normalize?  And what about the condition not to
> load it if uni-*.el files are unavailable?

Without ucs-normalize, some mysterious error occured during fontset
creation earlier in development, but it seems to be gone now, so I
deleted it along with the form that loaded `international/mule-util',
thanks.

>> --- a/src/floatfns.c
>> +++ b/src/floatfns.c
>> @@ -347,6 +347,19 @@ DEFUN ("logb", Flogb, Slogb, 1, 1, 0,
>>  double_integer_scale (double d)
>>  {
>>    int exponent = ilogb (d);
>> +#ifdef HAIKU
>> +  /* On Haiku, the values of FP_ILOGB0 and FP_ILOGBNAN are identical.
>> +     To top it all, both are also identical to INT_MAX.  */
>> +  if (exponent == FP_ILOGB0)
>> +    {
>> +      if (isnan (d))
>> +	return (DBL_MANT_DIG - DBL_MIN_EXP) + 2;
>> +      if (isinf (d))
>> +	return (DBL_MANT_DIG - DBL_MIN_EXP) + 1;
>> +
>> +      return (DBL_MANT_DIG - DBL_MIN_EXP);
>> +    }
>> +#endif

> I don't understand what the situation with FP_ILOGB0 has to do with
> logb function's implementation and the workaround you add here.
> Please clarify the comment.

Thanks, I tried.

>> -#ifdef USE_CAIRO
>> +#if defined (USE_CAIRO) || defined (USE_BE_CAIRO)

> Does this mean that USE_CAIRO code is not used by Haiku when Emacs is
> built with Cairo on Haiku?  Why is that?  And why cannot Haiku use
> USE_CAIRO?

USE_CAIRO, when defined, tries to define a lot of X related features
that aren't necessary.  USE_BE_CAIRO only enables the parts required for
the Cairo font driver to operate correctly.

>> diff --git a/src/haiku_draw_support.cc b/src/haiku_draw_support.cc
>> new file mode 100644
>> index 0000000000..c04bed81c2
>> --- /dev/null
>> +++ b/src/haiku_draw_support.cc

> There isn't a single comment in this and other Haiku-specific source
> files.  Please consider adding at least comments describing what the
> important non-trivial functions do and what their arguments mean.

Many of these functions are described in the header file defining their
prototypes, haiku_support.h.  The ones that are not documented (such as
most of the drawing functions) are ones that behave identically to the
Haiku counterparts they wrap (i.e. BView_FillTriangle), and ones that
behave identically to the documentation of Haiku functions by almost the
same name, but reimplemented to work around bugs in Haiku
(i.e. BView_DrawMask).

I may have missed a few of the function that do need documentation
though.  I fixed some of that in the revised patch.

> Btw, many comments in source files that are similar to X and w32 seem
> to have been copied wholesale from those other systems.  I have no way
> of verifying whether the copied comments are accurate for Haiku, so
> it's up to you to audit them.

I tried my best to audit those comments and delete the ones that did not
make sense.  Many of them are valid, because I have tried to keep the
code as close as possible to the X and w32 code.

>> +/* 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.

> Why not use script-representative-chars here?
>
>> +_Noreturn void
>> +gui_abort (const char *msg)
>> +{
>> +  fprintf (stderr, "Abort in GUI code: %s\n", msg);
>> +  fprintf (stderr, "Under Haiku, Emacs cannot recover from errors in GUI code\n");
>> +  fprintf (stderr, "App Server disconnects usually manifest as bitmap "
>> +	   "initialization failures or lock failures.");
>> +  emacs_abort ();
>> +}

> Are these writes to stderr going to stay in the production code?

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.)

>> +	key = strdup (ky);
>> +	if (!key)
>> +	  {
>> +	    perror ("strdup");
>> +	    gui_abort ("strdup failed");
>> +	  }
>> +      }
>> +
>> +    if (help)
>> +      {
>> +	this->help = strdup (help);
>> +	if (!this->help)
>> +	  {
>> +	    perror ("strdup");
>> +	    gui_abort ("strdup failed");
>> +	  }
>> +      }

> And these calls to perror?

The call to perror is redundant: gui_abort should suffice.  So they have
been deleted.

>> -#ifdef HAVE_EXT_MENU_BAR
>> +#if defined (HAVE_EXT_MENU_BAR) || defined (HAVE_HAIKU)

> Why is this needed?  You did define HAVE_EXT_MENU_BAR on Haiku, right?

Thanks, fixed.

>> @@ -3119,6 +3143,23 @@ list_system_processes (void)
>>    return  proclist;
>>  }
>>  
>> +#elif defined HAIKU
>> +
>> +Lisp_Object
>> +list_system_processes (void)
>> +{

> Can the Haiku-specific bits here be moved to some Haiku-specific file?

It would be more consistent with the other surrounding Unix variants
(i.e. GNU/Linux, Darwin, and the BSDs) to define them in that file.

But if you still insist, I have no objection it it.

> Thanks.

Thanks, please see the revised patch.

[haiku-emacs.patch (text/x-patch, attachment)]

Message #43 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 09:08:17 +0800
> 
> >> +  HAVE_M17N_FLT=no
> >> +  if test "${HAVE_LIBOTF}" = yes; then
> >> +    if test "${with_m17n_flt}" != "no"; then
> >> +      EMACS_CHECK_MODULES([M17N_FLT], [m17n-flt])
> >> +      if test "$HAVE_M17N_FLT" = "yes"; then
> >> +	AC_DEFINE(HAVE_M17N_FLT, 1, [Define to 1 if using libm17n-flt.])
> >> +      fi
> >> +    fi
> >> +  fi
> 
> > Do we need libm17n-flt?  For which font back-end is it needed?
> 
> The Cairo font backend has the ability to use libm17n-flt.  The code for
> that is in ftcrfont.c, as it is on X-Windows.

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.

> > This sounds no different from any other system, so I wonder why this
> > needs to be described.  On most systems, there's no Super or Hyper
> > keys, and they can be simulated via "C-x @", unless the user
> > configures the keyboard to do some remapping.
> 
> 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.

> >> +  On Haiku, Emacs defaults to using the system tooltip mechanism.
> >> +This usually leads to more responsive tooltips, but the tooltips will
> >> +not be able to use advanced display features.  If that is what you
> >> +need, you can disable the use of system tooltips by setting the
> >> +variable @code{haiku-use-system-tooltips} to nil. (@pxref{Tooltips,,,
> >> +elisp, The Emacs Lisp Reference Manual}).
> 
> > How is this different from the GTK build?  If it isn't different,
> > maybe it shouldn't be mentioned at all.
> 
> 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?

> >> +@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.

> >> +@item haiku-quit-requested
> >> +This event is received whenever the operating system tells Emacs that
> >> +the user has asked Emacs to quit, optionally seeking confirmation if
> >> +the user has any unsaved documents. By default, it is bound to
> >> +@code{save-buffers-kill-emacs}, see @ref{Exiting}.
> 
> > And this should be connected to the session manager, see xsmfns.c, and
> > then it can just trigger the mechanism defined there, as on other
> > platforms.
> 
> Isn't the mechanism there specific to X?

Which part is specific to X?

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?  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.

> >> @@ -2191,7 +2199,8 @@ Management Parameters
> >>  @code{mouse-autoselect-window} (@pxref{Mouse Window Auto-selection}).
> >>  This may have the unwanted side-effect that a user cannot scroll a
> >>  non-selected frame with the mouse.  Some window managers may not honor
> >> -this parameter.
> >> +this parameter.  On Haiku, it also has the side-effect that the window
> >> +will not be able to receive any keyboard input from the user.
> 
> > I don't understand: non-selected windows don't receive keyboard input
> > on all systems.  So what is special about Haiku here?
> 
> `no-accept-focus' means that the frame isn't willing to accept focus
> from mouse clicks and other mouse motion events.
> 
> On X-Windows, for instance, it is possible to give the keyboard focus to
> such a frame by hitting Alt-TAB (in most window managers); this is not
> possible on Haiku.

Then the text should explicitly mention Alt-TAB.

> > There isn't a single comment in this and other Haiku-specific source
> > files.  Please consider adding at least comments describing what the
> > important non-trivial functions do and what their arguments mean.
> 
> Many of these functions are described in the header file defining their
> prototypes, haiku_support.h.

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.

> >> +/* 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.

> >> +_Noreturn void
> >> +gui_abort (const char *msg)
> >> +{
> >> +  fprintf (stderr, "Abort in GUI code: %s\n", msg);
> >> +  fprintf (stderr, "Under Haiku, Emacs cannot recover from errors in GUI code\n");
> >> +  fprintf (stderr, "App Server disconnects usually manifest as bitmap "
> >> +	   "initialization failures or lock failures.");
> >> +  emacs_abort ();
> >> +}
> 
> > Are these writes to stderr going to stay in the production code?
> 
> 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.

> >> +Lisp_Object
> >> +list_system_processes (void)
> >> +{
> 
> > Can the Haiku-specific bits here be moved to some Haiku-specific file?
> 
> It would be more consistent with the other surrounding Unix variants
> (i.e. GNU/Linux, Darwin, and the BSDs) to define them in that file.
> 
> But if you still insist, I have no objection it it.

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

> Thanks, please see the revised patch.

Will review this later.

Message #46 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: 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.

Message #49 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 17:36:01 +0800
> 
> >> > 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.

How is POSITION used?  Can't you fake POSITION, so we get the same
event as on other platforms?

> > 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.

Every modern system has something similar, so it would make sense to
have a unified mechanism for handling those system messages in Emacs.
If xsmfns.c is too X-specific, we should build a layer above it, and
then implement th lower layer for Haiku.  It makes no sense to me to
introduce new events for specific platforms when similar features
already exist and just need to be extended or abstracted.

Message #52 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

Eli Zaretskii <eliz <at> gnu.org> writes:

> How is POSITION used?  Can't you fake POSITION, so we get the same
> event as on other platforms?

AFAIU, POSITION is used to determine the window where the file should
appear.  It should be possible to fake.

We could get the mouse position on-screen, but it may lead to odd
results if the user asks Emacs to open a file through the Tracker or the
Recents menu, and the mouse is not on top of an Emacs frame, or if the
system starts Emacs to open a file.

What position do you think would be reasonable to report here?

BTW, it seems that the NS port has the same problem here: it defines the
custom events `ns-open-file' and `ns-drag-and-drop' and `ns-power-off'.

> Every modern system has something similar, so it would make sense to
> have a unified mechanism for handling those system messages in Emacs.
> If xsmfns.c is too X-specific, we should build a layer above it, and
> then implement th lower layer for Haiku.  It makes no sense to me to
> introduce new events for specific platforms when similar features
> already exist and just need to be extended or abstracted.

Yes, makes sense.  It would be worthwhile just to solve this problem
with the NS port.  I will look into it.

Thanks in advance.

Message #55 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sun, 14 Nov 2021 18:39:04 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How is POSITION used?  Can't you fake POSITION, so we get the same
> > event as on other platforms?
> 
> AFAIU, POSITION is used to determine the window where the file should
> appear.  It should be possible to fake.
> 
> We could get the mouse position on-screen, but it may lead to odd
> results if the user asks Emacs to open a file through the Tracker or the
> Recents menu, and the mouse is not on top of an Emacs frame, or if the
> system starts Emacs to open a file.
> 
> What position do you think would be reasonable to report here?

The position in a window where your current code visits the file, I
guess?  Because this feature already works in your modified Emacs,
right?

> BTW, it seems that the NS port has the same problem here: it defines the
> custom events `ns-open-file' and `ns-drag-and-drop' and `ns-power-off'.

Which is BAAAAD!

> > Every modern system has something similar, so it would make sense to
> > have a unified mechanism for handling those system messages in Emacs.
> > If xsmfns.c is too X-specific, we should build a layer above it, and
> > then implement th lower layer for Haiku.  It makes no sense to me to
> > introduce new events for specific platforms when similar features
> > already exist and just need to be extended or abstracted.
> 
> Yes, makes sense.  It would be worthwhile just to solve this problem
> with the NS port.  I will look into it.

Thanks.

Message #58 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> AFAIU, POSITION is used to determine the window where the file should
>> appear.  It should be possible to fake.
>> 
>> We could get the mouse position on-screen, but it may lead to odd
>> results if the user asks Emacs to open a file through the Tracker or the
>> Recents menu, and the mouse is not on top of an Emacs frame, or if the
>> system starts Emacs to open a file.
>> 
>> What position do you think would be reasonable to report here?

> The position in a window where your current code visits the file, I
> guess?  Because this feature already works in your modified Emacs,
> right?

Yes, thanks, it makes sense now.

Message #61 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Mon, 15 Nov 2021 10:59:48 +0800

[Message part 1 (text/plain, inline)]

Po Lu <luangruo <at> yahoo.com> writes:

> AFAIU, POSITION is used to determine the window where the file should
> appear.  It should be possible to fake.
>
> We could get the mouse position on-screen, but it may lead to odd
> results if the user asks Emacs to open a file through the Tracker or the
> Recents menu, and the mouse is not on top of an Emacs frame, or if the
> system starts Emacs to open a file.
>
> What position do you think would be reasonable to report here?

I moved the Haiku system-dependents from sysdep.c to a separate file
`haiku.c'.  I also removed the extraneous events (drag-and-drop now
sends drag-n-drop events, like everywhere else, and haiku-quit-requested
has been removed for now.)

Here's an updated changelog.  Please see the attached patch, thanks.

Add support for the Haiku operating system and its window system 

* .gitignore: Add binaries specific to Haiku.

* Makefie.in (HAVE_BE_APP): New variable.
(install-arch-dep): Install Emacs and Emacs.pdmp when using Haiku.

* configure.ac: Detect and configure for Haiku and various related
 configurations.
(be-app, be-freetype, be-cairo): New options.
(HAVE_BE_APP, HAIKU_OBJ, HAIKU_CXX_OBJ)
(HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(HAIKU, HAVE_TINY_SPEED_T): New define.
(emacs_config_features): Add BE_APP.

* doc/emacs/Makefile.in (EMACSSOURCES): Add Haiku appendix.

* doc/emacs/emacs.texi: Add Haiku appendix to menus and
include it.

* doc/emacs/haiku.texi: New Haiku appendix.

* doc/lispref/display.texi (Defining Faces, Window Systems): Explain
haiku as a window system identifier.
(haiku-use-system-tooltips): Explain meaning of system tooltips on
Haiku.

* doc/lispref/frames.texi (Multiple Terminals): Explain meaning of
haiku as a display type.
(Frame Layout): Clarify section for Haiku frames.
(Size Parameters): Explain limitations of fullwidth and fullheight
on Haiku.
(Management Parameters): Explain limitations of inhibiting double
buffering on builds with Cairo, and the inability of frames with
no-accept-focus to receive keyboard input on Haiku.
(Font and Color Parameters): Explain the different font backends
available on Haiku.
(Raising and Lowering): Explain that lowering and restacking frames
doesn't work on Haiku.
(Child Frames): Explain oddities of child frame visibility on Haiku.

* doc/lispref/os.texi (System Environment): Explain meaning of haiku
.
* etc/MACHINES: Add appropriate notices for Haiku.
* etc/NEWS: Document changes.
* etc/PROBLEMS: Document font spacing bug on Haiku.

* lib-src/Makefile.in: Build be-resources binary on Haiku.
(CXX, CXXFLAGS, NON_CXX_FLAGS, ALL_CXXFLAGS)
(HAVE_BE_APP, HAIKU_LIBS, HAIKU_CFLAGS): New variables.
(DONT_INSTALL): Add be-resources binary if on Haiku.
(be-resources): New target.

* lib-src/be_resources: Add helper binary for setting resources on
the Emacs application.

* lib-src/emacsclient.c (decode_options): Set alt_display to "be"
on Haiku.

* lisp/cus-edit.el (custom-button, custom-button-mouse)
(custom-button-unraised, custom-button-pressed): Update face
definitions for Haiku.

* lisp/cus-start.el: Add haiku-debug-on-fatal-error and
haiku-use-system-tooltips.

* lisp/faces.el (face-valid-attribute-values): Clarify attribute
comment for Haiku.
(tool-bar): Add appropriate toolbar color for Haiku.

* lisp/frame.el (haiku-frame-geometry)
(haiku-mouse-absolute-pixel-position)
(haiku-set-mouse-absolute-pixel-position)
(haiku-frame-edges)
(haiku-frame-list-z-order): New function declarations.

(frame-geometry, frame-edges)
(mouse-absolute-pixel-position)
(set-mouse-absolute-pixel-position)
(frame-list-z-order): Call appropriate window system functions
on Haiku.

(display-mouse-p, display-graphic-p)
(display-images-p, display-pixel-height)
(display-pixel-width, display-mm-height)
(display-mm-width, display-backing-store)
(display-save-under, display-planes)
(display-color-cells, display-visual-class): Update type tests
for Haiku.

* lisp/international/mule-cmds.el (set-coding-system-map): Also
prevent set-terminal-coding-system from appearing in the menu bar
on Haiku.

* lisp/loadup.el: Load Haiku-specific files when built with Haiku,
and don't rename newly built Emacs on Haiku as BFS doesn't support
hard links.

* lisp/menu-bar.el (menu-bar-open): Add for Haiku.

* lisp/mwheel.el (mouse-wheel-down-event): Expect wheel-up on Haiku.
(mouse-wheel-up-event): Expect wheel-down on Haiku.
(mouse-wheel-left-event): Expect wheel-left on Haiku.
(mouse-wheel-right-event): Expect wheel-right on Haiku.

* lisp/net/browse-url.el (browse-url--browser-defcustom-type):
Add option for WebPositive.
(browse-url-webpositive-program): New variable.
(browse-url-default-program): Search for WebPositive.
(browse-url-webpositive): New function.

* lisp/net/eww.el (eww-form-submit, eww-form-file)
(eww-form-checkbox, eww-form-select): Define faces appropriately
for Haiku.

* lisp/term/haiku-win.el: New file.

* lisp/tooltip.el (menu-or-popup-active-p): New function declaration.
(tooltip-show-help): Don't use tooltips on Haiku when a menu is active.

* lisp/version.el (haiku-get-version-string): New function declaration.
(emacs-version): Add Haiku version string if appropriate.

* src/Makefile.in: Also produce binary named "Emacs" with Haiku resources
set.

(CXX, HAIKU_OBJ, HAIKU_CXX_OBJ, HAIKU_LIBS)
(HAIKU_CFLAGS, HAVE_BE_APP, NON_CXX_FLAGS, ALL_CXX_FLAGS): New
variables.

(.SUFFIXES): Add .cc.
(.cc.o): New target.
(base_obj): Add Haiku C objects.
(doc_obj, obj): Split objects that should scanned for documentation
into doc_obj.
(SOME_MACHINE_OBJECTS): Add appropriate Haiku C objects.
(all): Depend on Emacs and Emacs.pdmp on Haiku.
(LIBES): Add Haiku libraries.
(gl-stamp)
($(etc)/DOC): Scan doc_obj instead of obj
(temacs$(EXEEXT): Use C++ linker on Haiku.
(ctagsfiles3): New variable.
(TAGS): Scan C++ files.

* src/alloc.c (garbage_collect): Mark Haiku display.

* src/dispextern.h (HAVE_NATIVE_TRANSFORMS): Also enable on Haiku.
(struct image): Add fields for Haiku transforms.
(RGB_PIXEL_COLOR): Define to unsigned long on Haiku as well.
(sit_for): Also check USABLE_SIGPOLL.
(init_display_interactive): Set initial window system to Haiku on
Haiku builds.

* src/emacs.c (main): Define Haiku syms and init haiku clipboard.
(shut_down_emacs): Quit BApplication on Haiku and trigger debug
on aborts if haiku_debug_on_fatal_error.
(Vsystem_type): Update docstring.

* src/fileio.c (next-read-file-uses-dialog-p): Enable on Haiku.

* src/filelock.c (WTMP_FILE): Only define if BOOT_TIME is also
defined.

* src/floatfns.c (double_integer_scale): Work around Haiku libroot
brain damage.

* src/font.c (syms_of_font): Define appropriate font driver symbols
for Haiku builds with various options.

* src/font.h: Also enable ftcrfont on Haiku builds with Cairo.
(font_data_structures_may_be_ill_formed): Also enable on Haiku
builds that have FreeType or Cairo.

* src/frame.c (Fframep): Update doc-string for Haiku builds and
return haiku if appropriate.
(syms_of_frame): New symbol `haiku'.

* src/frame.h (struct frame): Add output data for Haiku.
(FRAME_HAIKU_P): New macro.
(FRAME_WINDOW_P): Test for Haiku frames as well.

* src/ftcrfont.c (RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG): New macros.
(ftcrfont_draw): Add haiku specific code for Haiku builds with Cairo.

* src/ftfont.c (ftfont_open): Set face.
(ftfont_has_char, ftfont_text_extents): Work around crash.
(syms_of_ftfont): New symbol `mono'.

* src/ftfont.h (struct font_info): Enable Cairo-specific fields for Cairo
builds on Haiku.

* src/haiku_draw_support.cc:
* src/haiku_font_support.cc:
* src/haiku_io.c:
* src/haiku_select.cc:
* src/haiku_support.cc:
* src/haiku_support.h:
* src/haikufns.c:
* src/haikufont.c:
* src/haikugui.h:
* src/haikuimage.c:
* src/haikumenu.c:
* src/haikuselect.c:
* src/haikuselect.h:
* src/haikuterm.c:
* src/haikuterm.h: Add new files for Haiku windowing support.

* src/haiku.c: Add new files for Haiku operating system support.

* src/image.c: Implement image transforms and native XPM support
on Haiku.

(GET_PIXEL, PUT_PIXEL, NO_PIXMAP)
(PIX_MASK_RETAIN, PIX_MASK_DRAW)
(RGB_TO_ULONG, RED_FROM_ULONG, GREEN_FROM_ULONG)
(BLUE_FROM_ULONG, RED16_FROM_ULONG, GREEN16_FROM_ULONG)
(BLUE16_FROM_ULONG): Define to appropriate values on Haiku.

(image_create_bitmap_from_data): Add Haiku support.
(image_create_bitmap_from_file): Add TODO on Haiku.
(free_bitmap_record): Free bitmap on Haiku.
(image_size_in_bytes): Implement for Haiku bitmaps.
(image_set_transform): Implement on Haiku.
(image_create_x_image_and_pixmap_1): Implement on Haiku, 24-bit or
1-bit only.
(image_destroy_x_image, image_get_x_image): Use correct img and
pixmap values on Haiku.
(lookup_rgb_color): Use correct macro on Haiku.
(image_to_emacs_colors): Implement on Haiku.
(image_disable_image): Disable on Haiku.
(image_can_use_native_api): Test for translator presence on Haiku.
(native_image_load): Use translator on Haiku.
(imagemagick_load_image): Add Haiku-specific quirks.
(Fimage_transforms_p): Allow rotate90 on Haiku.
(image_types): Enable native XPM support on Haiku.
(syms_of_image): Enable XPM images on Haiku.

* src/keyboard.c (kbd_buffer_get_event)
(handle_async_input, handle_input_available_signal)
(handle_user_signal, Fset_input_interrupt_mode)
(init_keyboard): Check for USABLE_SIGPOLL along with USABLE_SIGIO.

* src/lisp.h (pD): Work around broken Haiku headers.
(HAVE_EXT_MENU_BAR): Define on Haiku.
(handle_input_available_signal): Enable if we just have SIGPOLL
as well.

* src/menu.c (have_boxes): Return true on Haiku.
(single_menu_item): Enable toolkit menus on Haiku.
(find_and_call_menu_selection): Also enable on Haiku.

* src/process.c (keyboard_bit_set): Enable with only usable SIGPOLL.
(wait_reading_process_output): Test for SIGPOLL as well as SIGIO
availability.

* src/sound.c (sound_perror, vox_open)
(vox_configure, vox_close): Enable for usable SIGPOLL as well.

* src/sysdep.c (sys_subshell): Enable for usable SIGPOLL.
(reset_sigio): Make conditional on F_SETOWN.
(request_sigio, unrequest_sigio)
(emacs_sigaction_init): Also handle SIGPOLLs.
(init_sys_modes): Disable TCXONC usage on Haiku, as it doesn't
have any ttys other than pseudo ttys, which don't support C-s/C-q
flow control.
(speeds): Disable high speeds if HAVE_TINY_SPEED_T.

* src/termhooks.h (enum output_method): Add output_haiku.
(struct terminal): Add Haiku display info.
(TERMINAL_FONT_CACHE): Enable for Haiku.

* src/terminal.c (Fterminal_live_p): Return `haiku' if appropriate.
* src/verbose.mk.in (AM_V_CXX, AM_V_CXXLD): New logging variables.

* src/xdisp.c (redisplay_internal, note_mouse_highlight): Return on
Haiku if a popup is activated.
(display_menu_bar): Return on Haiku if frame is a Haiku frame.

* src/xfaces.c (GCGraphicsExposures): Enable correctly on Haiku.
(x_create_gc): Enable dummy GC code on Haiku.

* src/xfns.c (x-server-version, x-file-dialog): Add Haiku specifics
to doc strings.

* src/xterm.c (syms_of_xterm): Add Haiku information to doc string.

[haiku-emacs.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

> Yes, makes sense.  It would be worthwhile just to solve this problem
> with the NS port.  I will look into it.

I haven't had time to look at this yet, but I will in a bit.  Thanks.

Message #64 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 15:03:11 +0800

[Message part 1 (text/plain, inline)]

Po Lu <luangruo <at> yahoo.com> writes:

> I moved the Haiku system-dependents from sysdep.c to a separate file
> `haiku.c'.  I also removed the extraneous events (drag-and-drop now
> sends drag-n-drop events, like everywhere else, and haiku-quit-requested
> has been removed for now.)

This version of the patch doesn't apply to master any longer, so here's
an updated version.

The commit message shouldn't have to be updated.

[haiku-emacs.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Thanks.

Message #67 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 10:33:01 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 15:03:11 +0800
> 
> +The value of each variable can one of the symbols @code{command},
                              ^^^^^^^^^^^^^^^^^^^^^^
"can be one of the symbols"

> +  On Haiku, Emacs defaults to using the system tooltip mechanism.
> +This usually leads to more responsive tooltips, but the tooltips will
> +not be able to use advanced display features.  If that is what you
> +need, you can disable the use of system tooltips by setting the
> +variable @code{haiku-use-system-tooltips} to nil.

 "If you need those features, customize the variable
 @code{haiku-use-system-tooltips} to the nil value, and Emacs will use
 its own implementation of tooltips."

(And which advanced display features are those?  Perhaps they are
important enough to have this variable be nil by default?

> +                                                  (@pxref{Tooltips,,,
> +elisp, The Emacs Lisp Reference Manual}).

This should be @xref and without the parens.  Also, make sure you
leave 2 spaces between sentences.

> +@table @code
> +@vindex haiku-use-system-tooltips
> +@item haiku-use-system-tooltips
> +This variable controls whether or not system tooltips will be used.
> +
> +When non-nil, tooltips are displayed by the Application Kit and not
> +Emacs, and accordingly do not have a tooltip frame.  As such, they are
> +also unable to utilize any display properties.
> +@end table

Since you already explained what this does and mentioned the variable
name, this @table seems redundant.  Just move the @vindex entry to the
above text.

> +  Two of these backends, @code{ftcr} and @code{ftcrfont} are identical
                                  ^^^^
"ftcr" or "ftfont"?  Or maybe you meant ftcrfont and ftcrhb?

> @@ -3143,6 +3155,9 @@ Raising and Lowering
>  below all other frames belonging to the same or a higher z-group as
>  @var{frame}.  If @var{frame} is a child frame (@pxref{Child Frames}),
>  this lowers @var{frame} below all other child frames of its parent.
> +
> +@footnote{Lowering frames is not supported on Haiku, due to limitations
> +imposed by the system.}

@footnote generates a superscript number, so it should follow some
text, presumably the last sentence before it.  Please see how
@footnote is used elsewhere in the manual.

>  Some window managers may refuse to restack windows.
> +
> +@footnote{Restacking frames is not supported on Haiku, due to limitations
> +imposed by the system.}

Likewise.

> @@ -3272,6 +3290,12 @@ Child Frames
>  allowing them to be positioned so they do not obscure the parent frame
>  while still being visible themselves.
>  
> +@footnote{On Haiku, child frames are only visible when a parent frame is
> +active, owing to a limitation of the Haiku windowing system.  Owing to
> +the same limitation, child frames are only guaranteed to appear above
> +their top-level parent; that is to say, the top-most frame in the
> +hierarchy, which does not have a parent frame.}

Likewise.

> +** Emacs has been ported to the Haiku operating system.
> +The configuration process should automatically detect and build for Haiku.
> +There is also an optional window-system port to Haiku, which can be enabled
> +by configuring Emacs with the option '--with-be-app', which will require
> +the Haiku Application Kit development headers and a C++ compiler to be present
> +on your system.  If Emacs is not built with the option '--with-be-app', the
> +resulting Emacs will only run in text-mode terminals.
> +
> ++++
> +*** Cairo drawing support has been enabled for Haiku builds.
> +To enable Cairo support, ensure that the Cairo and FreeType development files
> +are present on your system, and configure Emacs with '--with-be-cairo'.
> +
> +---
> +*** Double buffering is now enabled on the Haiku operating system.
> +Unlike X, there is no compile-time option to enable or disable double-buffering.
> +If you wish to disable double-buffering, change the frame parameter
> +`inhibit-double-buffering' instead.
> +

The lines in these NEWS entries are too long, please use the default
value of fill-column when you file them.

>  ** Emacs now installs the ".pdmp" file using a unique fingerprint in the name.
>  The file is typically installed using a file name akin to
>  "...dir/libexec/emacs/29.1/x86_64-pc-linux-gnu/emacs-<fingerprint>.pdmp".
> diff --git a/etc/PROBLEMS b/etc/PROBLEMS
> index f506881a4b..c548ee9b36 100644
> --- a/etc/PROBLEMS
> +++ b/etc/PROBLEMS
> @@ -1022,6 +1022,15 @@ modern fonts are used, such as Noto Emoji or Ebrima.
>  The solution is to switch to a configuration that uses HarfBuzz as its
>  shaping engine, where these problems don't exist.
>  
> +** On Haiku, some proportionally-spaced fonts display with artifacting.
> +
> +This is a Haiku bug: https://dev.haiku-os.org/ticket/17229, which can
> +be remedied by using a different font that does not exhibit this
> +problem, or by compiling Emacs with the FreeType font driver.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This would benefit from telling what configure option or run-time
command-line arguments to use to do that.

>  (defun tooltip-show-help (msg)
>    "Function installed as `show-help-function'.
>  MSG is either a help string to display, or nil to cancel the display."
> -  (if (display-graphic-p)
> +  (if (and (display-graphic-p)
> +           (or (not (eq window-system 'haiku)) ;; On Haiku, there isn't a reliable way to show tooltips
> +                                               ;; above menus.
> +               (not (menu-or-popup-active-p))))

This seems to contradict what you wrote in the user manual about
tooltip options?

> +  while (get_next_team_info (&cookie, &info) == B_OK)
> +    {
> +      lval = Fcons (make_fixnum (info.team), lval);
> +    }

These braces are redundant.

> diff --git a/src/sysdep.c b/src/sysdep.c
> index 8eaee22498..67b6b2aa3d 100644
> --- a/src/sysdep.c
> +++ b/src/sysdep.c
> @@ -71,6 +71,10 @@
>  # include <math.h>
>  #endif
>  
> +#ifdef HAIKU
> +#include <kernel/OS.h>
> +#endif

Is this include still needed in sysdep.c?

Message #70 received at 51658 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>>  (defun tooltip-show-help (msg)
>>    "Function installed as `show-help-function'.
>>  MSG is either a help string to display, or nil to cancel the display."
>> -  (if (display-graphic-p)
>> +  (if (and (display-graphic-p)
>> +           (or (not (eq window-system 'haiku)) ;; On Haiku, there isn't a reliable way to show tooltips
>> +                                               ;; above menus.
>> +               (not (menu-or-popup-active-p))))

> This seems to contradict what you wrote in the user manual about
> tooltip options?

This only disables tooltips on Haiku if a menu or popup is active, as
Haiku doesn't let you map windows or tooltips above them.

Here's a patch with the other issues you mentioned fixed.  Please see if
it's better, thanks.

[haiku-emacs.patch (text/x-patch, attachment)]

Message #73 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 11:56:31 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 17:34:44 +0800
> 
> >>  (defun tooltip-show-help (msg)
> >>    "Function installed as `show-help-function'.
> >>  MSG is either a help string to display, or nil to cancel the display."
> >> -  (if (display-graphic-p)
> >> +  (if (and (display-graphic-p)
> >> +           (or (not (eq window-system 'haiku)) ;; On Haiku, there isn't a reliable way to show tooltips
> >> +                                               ;; above menus.
> >> +               (not (menu-or-popup-active-p))))
> 
> > This seems to contradict what you wrote in the user manual about
> > tooltip options?
> 
> This only disables tooltips on Haiku if a menu or popup is active, as
> Haiku doesn't let you map windows or tooltips above them.

But the manual doesn't mention that limitation, does it?

Does this limitation also affect tooltips produced by Emacs as special
frames?

> Here's a patch with the other issues you mentioned fixed.  Please see if
> it's better, thanks.

If you fixed everything and feel confident you did, just install it.
If there are some places where you want my opinion, please show only
those few places.

Thanks.

Message #76 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 21:08:29 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This only disables tooltips on Haiku if a menu or popup is active, as
>> Haiku doesn't let you map windows or tooltips above them.

> But the manual doesn't mention that limitation, does it?

Is that limitation important enough to mention?  It is not something
that is likely to happen at all.

> Does this limitation also affect tooltips produced by Emacs as special
> frames?

Yes, and all other windows as well.

> If you fixed everything and feel confident you did, just install it.
> If there are some places where you want my opinion, please show only
> those few places.

Thanks for the clarification.  I'll test again to see if it builds on
X-Windows and then install it.

Please let me know if it breaks the build on MS-Windows or some other
platform.

Message #79 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 15:30:11 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 21:08:29 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> This only disables tooltips on Haiku if a menu or popup is active, as
> >> Haiku doesn't let you map windows or tooltips above them.
> 
> > But the manual doesn't mention that limitation, does it?
> 
> Is that limitation important enough to mention?  It is not something
> that is likely to happen at all.

maybe I don't understand something: tooltips for menu items are
routinely shown in Emacs, so how come you say it is unlikely to
happen?

Message #82 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 21:33:29 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Is that limitation important enough to mention?  It is not something
>> that is likely to happen at all.

> maybe I don't understand something: tooltips for menu items are
> routinely shown in Emacs, so how come you say it is unlikely to
> happen?

Basically, tooltips for menu bar items get shown in the echo area
instead, because it's impossible to display tooltips above the menu bar.

For ordinary popup menus, I implemented a hack that allows to display
tooltips correctly.

Thanks.

Message #85 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 15:41:37 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 21:33:29 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Is that limitation important enough to mention?  It is not something
> >> that is likely to happen at all.
> 
> > maybe I don't understand something: tooltips for menu items are
> > routinely shown in Emacs, so how come you say it is unlikely to
> > happen?
> 
> Basically, tooltips for menu bar items get shown in the echo area
> instead, because it's impossible to display tooltips above the menu bar.

So this is not "unlikely" to happen, right?  As soon as the user tries
to use the menu-bar menus, the help-echo text will be shown in the
echo-area and not as a tooltip, right?  If so, I think this is very
important to mention in the Haiku appendix.

Message #88 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 21:45:41 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> So this is not "unlikely" to happen, right?  As soon as the user tries
> to use the menu-bar menus, the help-echo text will be shown in the
> echo-area and not as a tooltip, right?  If so, I think this is very
> important to mention in the Haiku appendix.

Thanks, I added a short passage to haiku.texi explaining this:

  Both system tooltips and Emacs's own tooltips cannot display above
the menu bar, so help text in the menu bar will display in the echo
area instead.

WDYT?

Message #93 received at 51658-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51658-done <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 21:51:39 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks for the clarification.  I'll test again to see if it builds on
> X-Windows and then install it.

It does, so installed with a change to the documentation.

> Please let me know if it breaks the build on MS-Windows or some other
> platform.

This still applies.  Many thanks in advance!

Message #96 received at 51658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658 <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 15:55:59 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658 <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 21:45:41 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > So this is not "unlikely" to happen, right?  As soon as the user tries
> > to use the menu-bar menus, the help-echo text will be shown in the
> > echo-area and not as a tooltip, right?  If so, I think this is very
> > important to mention in the Haiku appendix.
> 
> Thanks, I added a short passage to haiku.texi explaining this:
> 
>   Both system tooltips and Emacs's own tooltips cannot display above
> the menu bar, so help text in the menu bar will display in the echo
> area instead.

OK.

Message #99 received at 51658-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 51658-done <at> debbugs.gnu.org
Subject: Re: bug#51658: [PATCH] Haiku port (again)
Date: Sat, 20 Nov 2021 16:15:12 +0200

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: 51658-done <at> debbugs.gnu.org
> Date: Sat, 20 Nov 2021 21:51:39 +0800
> 
> > Please let me know if it breaks the build on MS-Windows or some other
> > platform.
> 
> This still applies.  Many thanks in advance!

Nothing seems to be broken.  Good job!

Previous Next

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