From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30874: 27.0.50; Emacs crashes Date: Thu, 29 Mar 2018 20:07:54 +0300 Message-ID: <83sh8idd3p.fsf@gnu.org> References: <837eq7lzr4.fsf@gnu.org> <831sgencgb.fsf@gnu.org> <83woy4i7rz.fsf@gnu.org> <83vadoi2ia.fsf@gnu.org> <878taf2kj5.fsf@gmail.com> <83d0zqg8p8.fsf@gnu.org> <87o9ja230e.fsf@gmail.com> <83605ig2se.fsf@gnu.org> <87fu4m1tht.fsf@gmail.com> <878tae1nzu.fsf@gmail.com> <83lgeedxv7.fsf@gnu.org> <874ll128ww.fsf@gmail.com> <83efk3dvq0.fsf@gnu.org> <87po3mdfl8.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1522343231 3561 195.159.176.226 (29 Mar 2018 17:07:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 17:07:11 +0000 (UTC) Cc: 30874@debbugs.gnu.org, jsynacek@redhat.com To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 29 19:07:06 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1b0z-0000pp-Ht for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 19:07:05 +0200 Original-Received: from localhost ([::1]:41134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1b33-0000QU-6d for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Mar 2018 13:09:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1b2v-0000OP-Ir for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 13:09:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1b2s-0001bZ-Ce for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 13:09:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51037) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1b2s-0001bJ-8I for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 13:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1f1b2r-0007VE-Vu for bug-gnu-emacs@gnu.org; Thu, 29 Mar 2018 13:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Mar 2018 17:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30874 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30874-submit@debbugs.gnu.org id=B30874.152234330328797 (code B ref 30874); Thu, 29 Mar 2018 17:09:01 +0000 Original-Received: (at 30874) by debbugs.gnu.org; 29 Mar 2018 17:08:23 +0000 Original-Received: from localhost ([127.0.0.1]:58934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1b2F-0007UO-1z for submit@debbugs.gnu.org; Thu, 29 Mar 2018 13:08:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60503) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1b2D-0007UC-TN for 30874@debbugs.gnu.org; Thu, 29 Mar 2018 13:08:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1b27-0000mw-Ew for 30874@debbugs.gnu.org; Thu, 29 Mar 2018 13:08:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1b22-0000gY-4W; Thu, 29 Mar 2018 13:08:10 -0400 Original-Received: from [176.228.60.248] (port=3066 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f1b21-0005ln-LA; Thu, 29 Mar 2018 13:08:10 -0400 In-reply-to: <87po3mdfl8.fsf@gmail.com> (message from Robert Pluim on Thu, 29 Mar 2018 18:14:11 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:144695 Archived-At: > From: Robert Pluim > Cc: 30874@debbugs.gnu.org, jsynacek@redhat.com > Date: Thu, 29 Mar 2018 18:14:11 +0200 > > > We already use fontconfig to some extent, and xftfont is AFAIK the > > most advanced font backend we have. Patches for switching to using > > more of fontconfig's features (assuming it can replace Xft), or for > > switching to a more modern back-end (harfbuzz?) are welcome, but I > > don't hold my breath, as I don't think we have expert on board who > > know enough about complex script shaping to make progress in those > > directions. > > As I understand it, we should use fontconfig for finding fonts, > harfbuzz for doing the layout, and cairo to actually render the > result Does harfbuzz require Cairo? If it does, that's unfortunate, because the Cairo rendering option currently has a few known and annoying redisplay bugs, which no one seems to be willing/capable of fixing. > plus itʼs Emacs redisplay, which Iʼm told is scary Don't believe the rumors too much. Besides, adding a font backend doesn't require to mess with the display code in any way, all you need is implement the interfaces you see documented in 'struct font_driver' defined in font.h (reusing the methods of existing backends where appropriate, as xftfont does with ftfont methods); all the rest is already taken care of in the infrastructure. The only interface between font back-end methods and the display engine is via 'struct glyph_string', which is a relatvely simple data structure. > I do note we have an Xft font backend, a freetype one, and a > freetype+cairo one already, which seems excessive. You forgot xfont and freetype-without-XFT. It could be that we could remove some of them, but I don't know which ones are used and how much. And freetype+cairo is not used much because of the Cairo problems. > > As a stopgap, I think we should find a way of ignoring the problematic > > fonts. Is there some way of detecting them? > > You mean short of running ftfont_get_bitmap over every available > codepoint in the font and skipping it if the resulting width * height > is > 4096 [1]? That would probably detect a problematic font pretty > quickly, but is not very elegant. Also Iʼm not sure we get to > intervene before Xft decides that it needs to fall back to that font. AFAIK, there's no "fallback" per se. Whenever the already-loaded fonts don't support a character, Emacs looks for the fonts that do using the "match" method. If we always fail these fonts in that method, they will never be used. > > AFAICT, we could do that > > either in ftfont_match or in its subroutine ftfont_spec_pattern. We > > could then pretend that these fonts don't match any font spec, perhaps > > subject to some variable (which would provide a 'fire escape"), which > > I think would fix the problem. > > Iʼm hoping that matching on something like !'family emoji' would work, > although Iʼve not figured out how to express that in fontconfig-speak. I thought there could be a way of detecting those "color bitmap fonts" by examining their attributes in ftfont_match and/or ftfont_spec_pattern. Then we could return a failure indication for them.