emacs-devel
[Top][All Lists]
Advanced

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

Re: Haiku port


From: Eli Zaretskii
Subject: Re: Haiku port
Date: Thu, 26 Aug 2021 12:13:50 +0300

> Date: Thu, 26 Aug 2021 16:01:13 +0800
> From:  Po Lu via "Emacs development discussions." <emacs-devel@gnu.org>
> 
> 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.

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

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

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

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

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

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

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

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

> +(unless (featurep 'haiku)
> +  (error "%s: Loading ext-win without having Haiku"
> +         invocation-name))

Is this error really needed?

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

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



reply via email to

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