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

[Eli Zaretskii <eliz@gnu.org>]

> > 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?
> 
> No, because a character is displayable only if it's in that set of 
> at-most-512 characters.
> 
> > 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?
> 
> terminal_glyph_code gets the current set of at-most-512 displayable 
> characters from from the kernel.

Right, I missed the 512-character part.  Quite a limitation, btw.

So, the plan seems to be this:

  . make sure the terminal is in Unicode mode, and that the user
    didn't override by a call to set-terminal-coding-system
  . if a character has a glyph in the Unicode font, send a UTF-8
    encoding for the character to the screen, disregarding the
    terminal encoding as mandated by the locale
  . if the character doesn't have a glyph in the console font, treat
    it as glyphless
  . if the conditions in the first item above are not met, fall back
    to the current code which encodes using the terminal encoding

I notice that we don't use terminal_glyph_code when determining
whether a given character should be treated as glyphless, so I guess
that means we could produce something other than what
glyphless-char-display says for a given character; this should be
fixed.

Also, the above means set-locale-environment should not call
set-terminal-coding-system if the display is a Linux console that
supports this feature.

Is that right?