bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39892: 28.0.50; Crash when running async command


From: Eli Zaretskii
Subject: bug#39892: 28.0.50; Crash when running async command
Date: Thu, 05 Mar 2020 13:22:18 +0200

> From: Robert Pluim <address@hidden>
> Cc: address@hidden,  address@hidden,  Kenichi Handa
>  <address@hidden>
> Date: Thu, 05 Mar 2020 11:57:24 +0100
> 
> >>>>> On Thu, 05 Mar 2020 11:46:59 +0200, Eli Zaretskii <address@hidden> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]