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: Sun, 16 Apr 2017 13:25:42 -0700
> 
> Eli Zaretskii wrote:
> 
> > That depends on how easy it is to check whether the console is in
> > UTF-8 mode.  Isn't that just another ioctl?
> 
> Not as far as I know, for output mode. I looked for one and could not find it.

Then perhaps we should intuit that from terminal-coding-system.

> >>> 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
> 
> I don't see offhand how to distinguish a user's call to 
> set-terminal-coding-system from one that Emacs does internally as part of its 
> existing heuristics.

There are only a handful of such calls.  What I had in mind was to
review our heuristics and avoid calling set-terminal-coding-system
there.  Failing that, we could put a property on, say, the terminal
object to indicate whether the setting is by user or by Emacs.

> Plus, even if the user invokes set-terminal-coding-system, 
> when the Linux console is in UTF-8 mode (as it invariably is these days) 
> Emacs 
> will do the wrong thing if blindly follows the user's setting.

Sorry, I don't follow: what wrong thing will Emacs do in this case?
Did you mean the user invoked set-terminal-coding-system with UTF-8 as
argument or with some other encoding?

> > We've heard over the
> > years from several users who make a point of using non UTF-8 locales,
> 
> On Linux consoles? Who does that nowadays?

I think Alan does, and we now know that Kevin does as well.  Plus,
term/linux.el does this:

  (defun terminal-init-linux ()
    "Terminal initialization function for linux."
    (unless (terminal-coding-system)
      (set-terminal-coding-system 'iso-latin-1))

which I guess needs to be revised?

> CJK locales have never worked on the Linux console, so the only concerns here 
> are ISO 8859 Latin and Cyrillic consoles, that sort of thing.

What about ISO 8859-8 or ISO 8859-6?

> Generally 
> speaking, the rare people who care about Linux console encoding and want to 
> use 
> non-ASCII characters on their Linux consoles, switched from 8-bit locales to 
> UTF-8 long ago: the code was added to Linux in 2007 and UTF-8 mode was made 
> the 
> default, and users took the usual one to three years to switch. So this is 
> all 
> ancient history now by GNU/Linux standards. It's not clear that we can even 
> test 
> the old 8-bit mode any more; it didn't work on my Fedora 25 Linux console 
> when I 
> tried. It's a waste of time to write code that isn't needed and can't be 
> tested.

I see your point, but I think we've been burnt by such decisions in
the past, so I'd prefer to leave a fire escape for users who for some
reasons don't follow the above patterns.  And the code that supports
the 8-bit mode is already written, we just need to leave it in place
when some conditions aren't satisfied.

> > 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
> 
> Yes, exactly. A frame connected to a Linux console should act like a GUI 
> frame 
> not an ordinary tty frame, because we know which characters the console can 
> display and we don't have to resort to guesswork and user settings like we do 
> with an ordinary tty frame.

Well, actually the TTY frames also pretends to know which characters
the console can display, it just does a less than perfect job in the
case of a Linux console.  So I think most of the code to handle this
can be left intact, we just need to reference the char-table created
by calculate_glyph_code_table when appropriate.