emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Haiku port


From: Po Lu
Subject: Re: Haiku port
Date: Thu, 26 Aug 2021 17:50:06 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> 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.

Attachment: haiku-emacs.patch
Description: Rectified patch


reply via email to

[Prev in Thread] Current Thread [Next in Thread]