[Top][All Lists]

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

bug#26396: 25.1; char-displayable-p on a latin1 tty

From: Eli Zaretskii
Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty
Date: Mon, 10 Apr 2017 10:05:01 +0300

> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> > From: Kevin Ryde <address@hidden>
> > Date: Sun, 09 Apr 2017 15:16:18 +1000
> > 
> > > Please step through char-displayable-p, and see what
> > > doesn't work there in your case.
> > 
> > Ah, it gets to (internal-char-font nil #x2022) = 7, which goes to the
> > (<= 0 font-glyph) case and is t, not the terminal-coding-system checking
> > case.
> Then Emacs is doing TRT, AFAICT: it uses the GIO_UNIMAP that's
> available on your system to query the kernel about characters
> displayable by the console.  Are you saying that as a matter of fact
> that character cannot be displayed by the console, i.e. that the code
> which uses GIO_UNIMAP somehow misbehaves?

Ah, I think I see the problem: the console indeed supports that
character, but since terminal-coding-system is latin-1, it cannot
encode it, so you see a question mark instead, is that right?

Paul, could you please look into this?  I think the code in
char-displayable-p which looks at the result of internal-char-font
should only accept a non-negative value if the terminal-coding-system
supports the character.  IOW, the Linux console should not be
considered as being able to display a character unless the terminal
encoding can safely encode it.

reply via email to

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