unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Greg A. Woods" <woods@robohack.ca>
Cc: 53924@debbugs.gnu.org
Subject: bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs
Date: Tue, 15 Feb 2022 16:21:43 +0200	[thread overview]
Message-ID: <83zgms2oso.fsf@gnu.org> (raw)
In-Reply-To: <m1nJn9z-0036s20@more.local> (woods@robohack.ca)

> Date: Mon, 14 Feb 2022 18:01:43 -0800
> From: "Greg A. Woods" <woods@robohack.ca>
> Cc: GNU Emacs Bug Reports <53924@debbugs.gnu.org>
> 
> > > 	(font-families (cl-remove-duplicates
> > > 			(sort (font-family-list)
> > > 			      (lambda(x y) (string> (upcase x) (upcase y))))
> > > 			:test 'cl-equalp)))
> >
> > This is not recommended as a way to get useful fonts.
> 
> Perhaps you can explain that better or differently so I can try to
> understand?

Certainly.  Which part(s) would you like me to explain better?

> I chose font-family-list because it is (supposedly) window-system
> agnostic.  Indeed it works fine on macOS too, and it transparently even
> does approximately the right thing on a TTY.

font-family-list yields a list that includes fonts that are not
necessarily appropriate for Emacs.  As does x-list-fonts, if run with
just one argument.

> >  My suggestion
> > is to use the following instead:
> >
> >   (delete-dups
> >    (x-list-fonts "-*-*-medium-r-normal-*-*-*-*-*-*-iso10646-1"
> > 		 'default (selected-frame)))
> 
> BTW, delete-dups is wrong, but I finally found seq-uniq (to avoid
> cl-lib):

I don't see why delete-dups would be wrong here, but that's a tangent.

> 	(seq-uniq
> 	 (sort (font-family-list)
> 	       (lambda(x y) (string> (upcase x) (upcase y))))
> 	 (lambda(x y) (string= (upcase x) (upcase y))))

The problem with this is that it doesn't filter out fonts that are too
small for the frame, and fonts that cannot be used for the 'default'
face.  So the result is still unsafe.

> > Indeed, using x-list-fonts indiscriminately could very well include
> > fonts that Emacs cannot use or even those which will crash Emacs.
> 
> Indeed -- that's another reason why I chose not to use x-list-fonts!

But font-family-list is not better.  In fact, it's worse, because it
doesn't support the filtering x-list-fonts does when used with 3
arguments, and when the font XLFD pattern is set up to produce only
fonts that can be safely used in Emacs for the 'default' face.

> > Is this with the above Lisp program that tries all the fonts collected
> > by font-family-list, or is this with some other recipe to reproduce
> > the crash?  Also, was that in "emacs -Q"?
> 
> It turns out the crash happens with one font in particular,
> "Inconsolata".  I have some cleanup of the versions of that font in
> particular that I need to do to be sure I know which one is being used.
> 
> I can also now confirm the same crash occurs with both GTK+2.0 and with
> the Lucid (xaw3d) toolkits, and in both 26.1 and today's Git "master".

Can you show a simple Emacs -Q invocation with that font which
crashes?  Then I think I or someone else could look into the reasons.





  reply	other threads:[~2022-02-15 14:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 19:02 bug#53924: 26.1; fontification sometimes fails for some characters despite available glyphs Greg A. Woods
2022-02-10 20:21 ` Eli Zaretskii
2022-02-10 23:34   ` Greg A. Woods
2022-02-11  7:15     ` Eli Zaretskii
2022-02-11 21:56       ` Greg A. Woods
2022-02-13  6:06       ` Greg A. Woods
2022-02-13 11:53         ` Eli Zaretskii
2022-02-15  2:01           ` Greg A. Woods
2022-02-15 14:21             ` Eli Zaretskii [this message]
2022-02-15 22:04               ` Greg A. Woods
2022-02-16  2:32               ` Greg A. Woods
2022-02-16  3:36                 ` Eli Zaretskii
2022-02-16 21:55                   ` Greg A. Woods
2022-02-16 22:14                 ` Lars Ingebrigtsen
     [not found] ` <handler.53924.B.164452023325832.ack@debbugs.gnu.org>
2022-02-10 22:42   ` Greg A. Woods

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=83zgms2oso.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=53924@debbugs.gnu.org \
    --cc=woods@robohack.ca \
    /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).