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: Sat, 15 Apr 2017 14:12:40 -0700
> 
> 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.

That depends on how easy it is to check whether the console is in
UTF-8 mode.  Isn't that just another ioctl?  If doing so is not too
hard, I'd prefer to include such a test.  Users IME are likely to find
and (ab)use any dark corner they have at their disposal, and I'd
prefer to have a sound solution rather than leave subtle bugs that
wait to be reported.

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

Once again, checking this is easy, and I'd prefer that Emacs didn't
get in users' ways of doing what they want.  We've heard over the
years from several users who make a point of using non UTF-8 locales,
and I expect them to have reasons for that.  I wouldn't want us to
break their configurations.

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

Glyphless characters are those that cannot be displayed.  On GUI
frames, we determine that by looking up the character in the available
fonts; if none is available, we display the character as determined by
glyphless-char-display.  On TTY frames, we do it differently, and the
way we do it doesn't currently consult the char-table created by
calculate_glyph_code_table.  I'm saying that we should, because
otherwise we let certain characters be displayed with the console's
replacement glyph instead of the way mandated by glyphless-char-display.

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

I think we should.