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

[Eli Zaretskii]

> Cc: user42_kevin@yahoo.com.au, 26396@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 13 Apr 2017 13:58:45 -0700
> 
> On 04/13/2017 12:16 AM, Eli Zaretskii wrote:
> > Yes, that would be better.  But it's probably a non-trivial project,
> > since we'd need separate code to determine double-width glyphs,
> > padding glyphs, and perhaps also something special for composed
> > characters.  Does the Linux console allow us to figure out all of
> > that?
> 
> This should not be a problem, as the Linux console has only single-width 
> characters.

Are you sure?  AFAIU, the Linux console supports the BMP, and some of
the characters in the BMP are double-width (a.k.a. "full-width"), for
example U+1100, U+231A, U+2B1B, and others.  What does the Linux
console do when these characters are sent to the screen driver?

> > And what does "display as-is" means in practice?  Should we send to
> > the console the glyph codes corresponding to Unicode points, or should
> > we send UTF-8 encoded characters?
> 
> It depends on whether the console is in UTF-8 mode. If so, send UTF-8; 
> if not, send a byte that is transformed according to the current mapping 
> table into a Unicode value. I hope we don't need to bother with the 
> latter possibility.

What software puts the console in UTF-8 mode?  Is that the locale
setting?

> > (Is there some document which
> > describes these features in enough detail for us to figure out their
> > implications on Emacs display code?)
> 
> Nothing definitive, but there is:
> 
> http://www.tldp.org/LDP/LG/issue91/loozzr.html
> http://man7.org/linux/man-pages/man4/console_codes.4.html

Thanks, but that seems to be just the tip of an iceberg.  Or maybe the
issue is easier than I envisioned.

Suppose we only wanted to use this feature for UTF-8 locales.
Assuming that the OS takes care of putting the console in UTF-8 mode,
we don't need any changes in Emacs, since Emacs already sends UTF-8
sequences to the screen driver.  As the Linux console only supports
the BMP, we could then simply amend the code of char-displayable-p to
check whether a character is within the BMP, when the terminal is the
Linux console.  Do you agree with this conclusion?

OTOH, now I'm not sure I understand the need for terminal_glyph_code.
What does it do that a simple check for a Linux console and UTF-8
terminal encoding, plus a character being inside a BMP, don't?