From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#51658: [PATCH] Haiku port (again) Date: Sun, 14 Nov 2021 17:36:01 +0800 Message-ID: <877ddb6pvi.fsf@yahoo.com> References: <87ee7surtv.fsf.ref@yahoo.com> <87ee7surtv.fsf@yahoo.com> <83mtmd43fa.fsf@gnu.org> <87ilx0yj52.fsf@yahoo.com> <83czn8424l.fsf@gnu.org> <87o86s41at.fsf@yahoo.com> <83tugk2iuy.fsf@gnu.org> <871r3n4jvd.fsf@yahoo.com> <835ysz2niq.fsf@gnu.org> <87sfw3w372.fsf@yahoo.com> <83zgq7x5zj.fsf@gnu.org> <87r1bjlf26.fsf@yahoo.com> <83wnlbuq7p.fsf@gnu.org> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12096"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: 51658@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 14 10:37:32 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mmBx6-0002ye-5d for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Nov 2021 10:37:32 +0100 Original-Received: from localhost ([::1]:52130 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mmBx4-0000UF-VH for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 Nov 2021 04:37:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mmBwc-0008OZ-Mj for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 04:37:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mmBwc-0002Nn-Dg for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 04:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mmBwc-0003JH-CM for bug-gnu-emacs@gnu.org; Sun, 14 Nov 2021 04:37:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 Nov 2021 09:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51658 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51658-submit@debbugs.gnu.org id=B51658.163688258012666 (code B ref 51658); Sun, 14 Nov 2021 09:37:02 +0000 Original-Received: (at 51658) by debbugs.gnu.org; 14 Nov 2021 09:36:20 +0000 Original-Received: from localhost ([127.0.0.1]:49132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmBvw-0003ID-8a for submit@debbugs.gnu.org; Sun, 14 Nov 2021 04:36:20 -0500 Original-Received: from sonic307-56.consmr.mail.ne1.yahoo.com ([66.163.190.31]:40556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mmBvv-0003I1-0d for 51658@debbugs.gnu.org; Sun, 14 Nov 2021 04:36:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636882573; bh=czM/0NzB9GnmYr47pq2rfHhRxyuJEaE/zinPaf23SPY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=UfUNwmimbyc7NT7LnGmJl2LYUvWlWPzP9dY8vtuFCjQ5t+syTpzQVIj5bEJHyR1Rv9kniOo/geNGTNvj1CT/t1KjKl1n2R8CRGxoe6+tn0011DHebsSt8to2goR1YR7bsE1pfmNRlzDqAaWEiuZbDtKcClCUQJe+U1ujwlQoyHA7fOzom1T+/Ni/aMvq4ZyrxoeD0fSn/axp5Bxpa6IKL5Lp/LtY1bG/i8dO9hdOR9hnywnBT76dum/4VvA+VVhrYu0cBUly7OcCEtuR5kNAMR03h1EuFCgeuEaQPLYXBLWQFUcU9wiIDDRSAeZ/fX+9OOqVRGdagEqssCFyvIRu9w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1636882573; bh=1TCXtP0+leXazl8q3JFLY/8JlHMHaBP5dqamhmTvp3G=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=FOrx3/M+wLwYQHYqZlq0l0WQBlfCW6ZjkaycOWKI8RNUiDiJNRUr1ghnOOm2x+kkx07spUtAprlypPuUXhnnS4iMtUZe1JzAW/S3FhWOR0m6PURZvzKt39b/IotbP7rInGH+W0e0IDZ4jOPK5gBdmayJo8fw8Y+waTTroXPKx/gbfIzLV7EjZjndnXzv8wWih8ybrL1tCXPXtvqZhHKwy0oEE78dzxC6HvqA/u990A8h3/gttL0Hjy5zTF+/DWXc573og6OpoL74xVTzdVgYv6LBnUcRdzeBYON4t39VidqxJEmUOT8p/UgqUNoPl2bUxvLtWaGvdbCBzR5XcsA3fw== X-YMail-OSG: pvhApBcVM1mhIWLt0SNznagPwoEoa6trcvdwKG0SKFeoaMyaWl8kThwIqY6guKj TKiDOGuaXjgs8nsJjtS1rMs3wVqsrAkbHT9OGd95kGlBQluImZpbTMQmZvdW5G8SnCI6FkzOtwgT gUrI_2wwkaZ3zsYL9_67Y_z7A.k_TypJvKXP5O8GHUfgf5xth2bz5EQdiaHqRISOt_etI9BAlFJH iUE.XjZDeWq2UICaCL3_cI6i9_uTrLPmZNAM59yaZ9bhaBhS.EtWP8tOiJMayld9meFLvNvz2mlN oAAX5Jb5q5Z828z_5qJ9GdITqFyWhQYltUOqiHkYbs7_k4OgfrdRPqV54XbRu0P09xXHqTXgnEsn mH0hYxDelystSGHbIG06Ni7FOk2ZU3BU2vG6lRCuJvIxyW4OauvF5w2VNEKWH.SbDpoB2ehyZofo OEUt5BOSEqT0U732zWLSerxxl4pf.I455GpZJlyUibRCQNkOSIQgeEU5tutGv6GN7zTz1c93LrZO 1sSSOD8nI872vzEGkICaZt3Z7R60yxyUqyQ2IuOkALprkdfhgh0zqJmggdsg06tC.GGPiYEHv1sj kB9g493wdgk5_dp_FHMDraGGW.5QbTK_fnot4bhM7M114wxIHeXFo.PUMjK47R_XTt4EvbDYBwX2 15Xr6VmSGJCY9KF4HqiT5c6MDextb_zP3e40BOPlB0is4DwpQH7K2XaaU4zwLDhAndv96FcLJu3g mWM33F8iB2bTppZAYx.WIEESzAfNfSUpywag2hmuFNtb6mdhf_ghoLz0zURvx3EmZ1541j_KLb_w l_Z_lu8EExdIcJF11jg9FfycZkyz2Toq3rmlGHX9Gm X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.ne1.yahoo.com with HTTP; Sun, 14 Nov 2021 09:36:13 +0000 Original-Received: by kubenode503.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1586578d083e84d9d52f7e39f10d2019; Sun, 14 Nov 2021 09:36:06 +0000 (UTC) In-Reply-To: <83wnlbuq7p.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 14 Nov 2021 09:54:50 +0200") X-Mailer: WebService/1.1.19306 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:219919 Archived-At: Eli Zaretskii 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.