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

[Paul Eggert]

Eli Zaretskii wrote:
> So, the plan seems to be this:
>
>   . make sure the terminal is in Unicode mode,

I don't think we need to worry about whether the console is in UTF-8 mode. UTF-8 
mode has been the default for years, and unless the user goes to a good deal of 
trouble (and I suspect this part of the Linux kernel hasn't been tested 
recently) we can assume UTF-8 mode.

There is a subtlety here. The console can be in UTF-8 mode for input ('stty 
iutf8' vs 'stty -iutf8'), but that's not what we're concerned about: we're 
concerned whether it's in UTF-8 mode for output. I don't see how the user can 
affect the latter other than by outputting ESC % @ and ESC % G. And I just now 
tried outputting these sequences to my Linux console but they didn't seem to 
affect anything. Without the ability to test this stuff and with no real need to 
worry about it that I can see, I suggest that we just assume UTF-8 mode.

> and that the user
>     didn't override by a call to set-terminal-coding-system

It might be simpler to not worry about this, under the argument that the Linux 
console is not a terminal in the usual sense. Certainly set-locale-environment 
should not override the fact that Emacs is connected to a Linux console. (You 
mention this below.)

>   . 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

This sounds right.

>   . if the conditions in the first item above are not met, fall back
>     to the current code which encodes using the terminal encoding

As I mentioned above, perhaps we should not worry about those conditions and 
therefore not worry about falling back to the current code.

> 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.

Sorry, I am not quite following this, but yes the various parts of Emacs should 
be consistent in this area.

> 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.

This matters only if we worry about the terminal coding system in Linux 
consoles, which it isn't clear we should do.