Eli Zaretskii writes: >> So far, basic stuff works, though it is missing some functionality here >> and there, and I would not deem this port ready for serious work. >> However I haven't had time to work on tests and documentation; the >> tests, I can definitely work on, but I'm not sure from where I should >> begin updating the documentation, and would appreciate some advice. > What kind of documentation are we talking about here? Is that > user-level documentation, such as some Haiku-specific settings? If > so, a Haiku-specific Appendix, like we already have for some other > systems, would be a good place. There are currently no user-specific settings, but I was referring to the general changes with a new terminal driver. >> I also think the BFont font driver needs work -- it has artifacting with >> RTL text and when drawing condensed characters, but font rendering is >> quite certainly outside my field of expertise, and I would appreciate >> help from an expert. (Though, ideally, we would have a FreeType-based >> font driver, but I think FreeType is not easily usable within Haiku >> applications). > Can't you just use HarfBuzz? Can HarfBuzz be built for Haiku? We > generally are migrating to HarfBuzz as our main text-shaping engine, > so it would be good if Haiku supported that as well. A port of fthbfont would be well appreciated, but that's beyond my abilities at present. Help welcome :) >> The patch is attached below and should apply cleanly. I would >> appreciate any suggestions or comments. I think I have already signed >> the copyright assignment papers, but if not, I would be happy to sign >> again. > > I don't see your assignment on file, but maybe I'm not using the same > name and email address you used then? I think it's the same mail. Anyhow no worries, I'd be happy to sign again. >> And big oopsie right there... Some extraenous changes that I had >> reverted long ago found their way into the patch by means of magic. > > Thanks. Some comments below. > >> @@ -905,7 +912,7 @@ AC_DEFUN >> if test $emacs_cv_prog_cc_g3 != yes; then >> CFLAGS=$emacs_save_CFLAGS >> fi >> - if test $opsys = mingw32; then >> + if test $opsys = mingw32 || test $opsys = haiku; then >> CFLAGS="$CFLAGS -gdwarf-2" > Why did you need this? Isn't DWARF debug info the default on Haiku? > And if it isn't the default, do all the compilers you want to be able > to use support the -gdwarf-2 switch? Haiku's outdated version of the GNU Debugger only supports dwarf-2 debug information, and not the default dwarf-4 format their version of GCC builds programs with. As for compilers, I think only GCC is currently supported on Haiku. >> +if test "${opsys}" = "haiku" && test "${with_be_app}" = "yes"; then >> + AC_PROG_CXX([gcc cl KCC CC cxx cc++ xlC aCC c++ g++]) >> + CXXFLAGS="$CXXFLAGS $emacs_g3_CFLAGS" >> + AC_LANG_PUSH([C++]) > This seems to say you want to compile Emacs as a C++ program. Does > that really work? We don't require our C code to be C++-compatible. It does. The C++ code is entirely specific to Haiku windowing and is exposed to the rest of Emacs through extern "C" subroutines. >> @@ -3216,7 +3264,7 @@ AC_DEFUN >> dnl --with-toolkit-scroll-bars=no was specified. >> >> AH_TEMPLATE(USE_TOOLKIT_SCROLL_BARS, >> - [Define to 1 if we should use toolkit scroll bars.])dnl >> + [Define to 1 if we should use toolkit scroll bars.]) > What's the purpose of this hunk? I must've missed that. >> @@ -5006,8 +5057,8 @@ AC_DEFUN >> dnl to read the input and send it to the true Emacs process >> dnl through a pipe. >> case $opsys in >> - darwin | gnu-linux | gnu-kfreebsd ) >> - AC_DEFINE(INTERRUPT_INPUT, 1, [Define to read input using SIGIO.]) >> + darwin | gnu-linux | gnu-kfreebsd) >> + AC_DEFINE(INTERRUPT_INPUT, 1, [Define to read input using SIGIO or SIGPOLL.]) > And this one? Haiku only has SIGPOLL, not SIGIO, but the description change seems to be extraneous. >> @@ -8021,6 +8022,8 @@ Window Systems >> GNUstep and macOS). >> @item pc >> Emacs is displaying the frame using MS-DOS direct screen writes. >> +@item haiku >> +Emacs is displaying the frame using the Application Kit on Haiku > This should end in a period. >> --- a/etc/NEWS >> +++ b/etc/NEWS >> @@ -34,6 +34,13 @@ more details. >> --- >> ** Support for building with Motif has been removed. >> >> +** Emacs has been ported to the Haiku operating system > > And this also. I will correct that, thanks. >> +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. > Can you please make this description more detailed wrt the difference > between using '--with-be-app' and not using it? How will the built > Emacs be different in these two cases? Should I add something to the likes of "Without --with-be-app, Emacs will not have any code specific to Haiku windowing." to the NEWS entry? >> +(unless (featurep 'haiku) >> + (error "%s: Loading ext-win without having Haiku" >> + invocation-name)) > > Is this error really needed? It seems to be present in the rest of the FOO-win backends. >> + if (EQ (clipboard, QPRIMARY)) >> + dat = BClipboard_find_primary_selection_data (SSDATA (name)); >> + else if (EQ (clipboard, QSECONDARY)) >> + dat = BClipboard_find_secondary_selection_data (SSDATA (name)); >> + else if (EQ (clipboard, QCLIPBOARD)) >> + dat = BClipboard_find_system_data (SSDATA (name)); >> + else >> + { >> + unblock_input (); >> + signal_error ("Bad clipboard", clipboard); >> + } >> + unblock_input (); >> + >> + if (!dat) >> + return Qnil; >> + Lisp_Object str = build_string (dat); > Don't you need to decode the clipboard text before building an Emacs > Lisp string from it? If I'm not mistaken, the string should be UTF-8. Is build_string () insufficient? >> +#ifdef USABLE_SIGIO >> handle_input_available_signal (SIGIO); >> +#else >> + handle_input_available_signal (SIGPOLL); >> +#endif > Please keep our conventions for indentation in C sources: we use the > default value of indent-tabs-mode, so C sources are indented with a > mix of TABs and SPCs. That was a mistake, thanks for spotting it. I have attached a patch with some of the mistakes rectified, and will rectify the rest ASAP.