From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#51658: [PATCH] Haiku port (again) Date: Wed, 10 Nov 2021 16:19:49 +0200 Message-ID: <83tugk2iuy.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19211"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51658@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 10 15:21:50 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 1mkoU1-0004kS-JA for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Nov 2021 15:21:49 +0100 Original-Received: from localhost ([::1]:57476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mkoTz-0005Qb-Sh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Nov 2021 09:21:47 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48054) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkoTP-0005OG-Ef for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 09:21:12 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54187) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mkoTG-00036n-9W for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 09:21:10 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mkoTG-0001IE-0f for bug-gnu-emacs@gnu.org; Wed, 10 Nov 2021 09:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Nov 2021 14:21:01 +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.16365540054873 (code B ref 51658); Wed, 10 Nov 2021 14:21:01 +0000 Original-Received: (at 51658) by debbugs.gnu.org; 10 Nov 2021 14:20:05 +0000 Original-Received: from localhost ([127.0.0.1]:37500 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkoSL-0001GV-2Q for submit@debbugs.gnu.org; Wed, 10 Nov 2021 09:20:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkoSH-0001Fv-5w for 51658@debbugs.gnu.org; Wed, 10 Nov 2021 09:20:04 -0500 Original-Received: from [2001:470:142:3::e] (port=60778 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkoSA-0002qV-Jv; Wed, 10 Nov 2021 09:19:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hhJwVLjKm5VK9Cmzf+kzqqcFkUlvj2pvyJ59kV7puoA=; b=PhZEl5MnUxIN 8n1mDjU/OOfwau19mAPwRMtqRhJ1eQBfer0lWs/fXh0OORvzb06LnI0fAmHXKZ7ZGomFq/uxDoi7O 8tIEV4k9R07x0bpHD34gqWNrRZcrn9zY4cagPdKRnMUQxpmUkml+CbZq/gSwkjGiR+mDgVqF7Wl3T 6iz/Sp8euqfi0iWbXoJmpfkHMVB4DJb5lFwXa5mpFFG7IKnV4JAxNlk3JwK6UCJ3XZhgSs+oIKKOR x0acxGCYpqiFidkb0wwIBWt0jiMUIAEm2Bvst1Bb60Z8FKdiG9loL9HS0P3XnJYc71Krl4FayVRJf ibzRqzmHJ18jY4qBbAbeCg==; Original-Received: from [87.69.77.57] (port=2223 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mkoSA-0007VN-8A; Wed, 10 Nov 2021 09:19:54 -0500 In-Reply-To: <87o86s41at.fsf@yahoo.com> (message from Po Lu on Wed, 10 Nov 2021 20:56:10 +0800) 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:219549 Archived-At: > From: Po Lu > Cc: 51658@debbugs.gnu.org > Date: Wed, 10 Nov 2021 20:56:10 +0800 > > Eli Zaretskii writes: > > > Too bad. IMNSHO, that's a ticking time bomb, and it will certainly > > bite us at some point, since mixing C and C++ is tricky and requires a > > lot of diligence. It also means that you will probably be unable to > > use any compiler but GCC (or whatever is currently supported by > > Haiku), since different C++ compilers are generally > > binary-incompatible. > > AFAIU, the Haiku developers only support GCC for compiling C++ code, as > they have a requirement to keep support for old BeOS software, which > depends on the GCC ABI. And for a good reason. Then I think you should remove the part of configure.ac that looks for other C++ compilers, as that is entirely unnecessary, and probably will always be. > > Since you later say Cairo is unreliable, why not drop Cairo? > > What I meant by "unreliable" is that the Haiku developers tend to tweak > their Cairo package in various manners, which breaks the Emacs build. > > People building Cairo themselves won't experience this problem, but > building the BeOS cairo backend is... tricky, to say the least. I > managed to get it to work, but there is a lot of pain involved in it > that I wouldn't want to repeat. > > The Haiku developers have a package repository and build automation > system that would make this easy, should they ship the Haiku port of > Emacs in the future. (At present, they only ship Emacs built to run in > a TTY.) > > So it is useful to have Cairo around, for people whom it is useful, but > if not, it would be good to have something to fall back to. > > > And that still leaves us with 3 backends, IIUC. Why not just one? > > Well, one of those backends is simply a HarfBuzz variant of the other, > which is how xftfont and ftcrfont do it, and IIUC, that's how it works > under MS-Windows too. The other platforms have past history, which Haiku doesn't. And we plan on removing more old backends in the future; for example Uniscribe for Windows will die soon enough because MS deprecated it, and it is not being developed anymore, so falls behind in supporting new scripts and features. > So, if we keep only the haikufont backend (for Haiku users who don't > want to install FreeType or Cairo), and one of `ftbe' or cairo font > support, there will really just be two font backends. OK, let's go with two. I understand that both will use HarfBuzz? I'd prefer not to have backends that use other shaping engines, unless Haiku has some shaping engine that is better than HarfBuzz. > Aside from not depending on Cairo or FreeType, which are not always > available on Haiku, it also comes with the advantage of being fast even > on remote sessions (not unlike X11 remote access), as characters drawn > are sent down the wire as plain text, instead of as bitmap data, which > is very slow when operating over a remote connection. > > So I think it will be useful as a fallback in many cases. I hope you will reconsider. Having a niche platform with 3 font backends is really too much. Especially since Emacs 29 learned to display Emoji now, and we are talking about adding decent support for ligatures, both of which require a shaping engine. > > So my suggestion is to choose wisely which features you really need to > > keep. > > Yes, thanks. OK, please post an updated patch, and we'll take it from there. Thanks.