[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.
haiku-emacs.patch
Description: Rectified patch
- Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Eli Zaretskii, 2021/08/26
- Re: Haiku port,
Po Lu <=
- Re: Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Eli Zaretskii, 2021/08/26
- Re: Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Eli Zaretskii, 2021/08/26
- Re: Haiku port, Po Lu, 2021/08/26
- Re: Haiku port, Eli Zaretskii, 2021/08/27
- Re: Haiku port, Po Lu, 2021/08/28
Re: Haiku port, Werner LEMBERG, 2021/08/26