GNU bug report logs - #26396
25.1; char-displayable-p on a latin1 tty

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>, user42_kevin <at> yahoo.com.au
Cc: 26396 <at> debbugs.gnu.org
Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty
Date: Mon, 10 Apr 2017 10:05:01 +0300

> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 26396 <at> debbugs.gnu.org
> 
> > From: Kevin Ryde <user42_kevin <at> yahoo.com.au>
> > 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.