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>
Cc: user42_kevin <at> yahoo.com.au, 26396 <at> debbugs.gnu.org
Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty
Date: Mon, 17 Apr 2017 11:08:15 +0300

> Cc: user42_kevin <at> yahoo.com.au, 26396 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sun, 16 Apr 2017 23:41:33 -0700
> 
> Eli Zaretskii wrote:
> > I can offer help in reviewing the patches and perhaps also writing
> > some of that, but I cannot test the code, as I don't have a convenient
> > access to a Linux console where I could run Emacs I build.
> 
> Rather than descend into this swamp I am hoping that the patch I installed is 
> enough to solve Kevin's problem.

I thought we were discussing a broader issue: how to make Emacs work
better on a Linux console, not just how to fix char-displayable-p.

At the very least, I think we should teach Emacs to call
terminal_glyph_code when it decides whether a given character should
be displayed as glyphless or not.  E.g., what do you get on a Linux
console when trying to output a character beyond the BMP, like u+17001
or u+1F800? do you get the expected \uNNNNN representation?  And what
does Emacs display for characters from the BMP that are not supported
by the console's font?

My reading of the code is that at least some of these unsupported
characters will NOT be displayed as \uNNNNN, but rather as some
fallback glyph produced by the console itself, which is not what we
want, I think.

Thanks.

Previous Next

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