GNU bug report logs -
#39892
28.0.50; Crash when running async command
Previous Next
Reported by: Ravine Var <ravine.var <at> gmail.com>
Date: Wed, 4 Mar 2020 02:52:02 UTC
Severity: normal
Found in version 28.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: ravine.var <at> gmail.com, 39892 <at> debbugs.gnu.org, Kenichi Handa
> <handa <at> gnu.org>
> Date: Thu, 05 Mar 2020 11:57:24 +0100
>
> >>>>> On Thu, 05 Mar 2020 11:46:59 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>
> Eli> How about the patch below? It works for me, and seems to be TRT in
> Eli> general, since it makes the code more defensive in the face of
> Eli> possible nil values in that vector, which are legitimate according to
> Eli> my reading of the commentary at the beginning of fontset.c.
>
> That patch works for me.
Thanks for testing. I will wait for Ravine to confirm it fixes the
original use case.
> >> Btw, U+E9F8 is a PUA character; how did it get into a context where we
> >> are trying to display it?
>
> Eli> I'd still like to know the answer to this. It seems like something
> Eli> fishy is going on in the original use case that requires us to try to
> Eli> display this PUA codepoint.
>
> Itʼs essentially doing 'cat' on a .gz file.
I see. But I guess there was some real-life use case behind all that?
I mean, why would someone want to dump a Gzip-compressed text to the
screen, and inside Emacs on top of that?
> Interestingly, under macOS it displays a proper glyph using
> "mac-ct:-*-Hannotate TC-normal-normal-normal-*-14-*-*-*-p-0-iso10646-1
> (#x933F)", so somebody has decided that codepoint is good for something.
Yes, some fonts usurp the PUA for displaying characters not (yet) in
Unicode. This being a font for Chinese, I guess they use it for
characters in GB-18030 that don't map to Unicode, or somesuch.
This bug report was last modified 5 years and 74 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.