unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 51658@debbugs.gnu.org
Subject: bug#51658: [PATCH] Haiku port (again)
Date: Sun, 14 Nov 2021 17:36:01 +0800	[thread overview]
Message-ID: <877ddb6pvi.fsf@yahoo.com> (raw)
In-Reply-To: <83wnlbuq7p.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Nov 2021 09:54:50 +0200")

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





  reply	other threads:[~2021-11-14  9:36 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87ee7surtv.fsf.ref@yahoo.com>
2021-11-07 11:29 ` bug#51658: [PATCH] Haiku port (again) Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-09 17:58   ` Eli Zaretskii
2021-11-10  0:00     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-10  4:33       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-10 12:38       ` Eli Zaretskii
2021-11-10 12:56         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-10 14:19           ` Eli Zaretskii
2021-11-11  0:27             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-11  6:51               ` Eli Zaretskii
2021-11-11  7:40                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-13 18:31                   ` Eli Zaretskii
2021-11-14  1:08                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14  7:54                       ` Eli Zaretskii
2021-11-14  9:36                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-11-14 10:28                           ` Eli Zaretskii
2021-11-14 10:39                             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-14 10:54                               ` Eli Zaretskii
2021-11-14 11:06                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-15  2:59                               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20  7:03                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20  8:33                                   ` Eli Zaretskii
2021-11-20  9:34                                     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20  9:56                                       ` Eli Zaretskii
2021-11-20 13:08                                         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20 13:30                                           ` Eli Zaretskii
2021-11-20 13:33                                             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20 13:41                                               ` Eli Zaretskii
2021-11-20 13:45                                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20 13:55                                                   ` Eli Zaretskii
2021-11-20 13:51                                           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-20 14:15                                             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877ddb6pvi.fsf@yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=51658@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).