GNU bug report logs - #26396
25.1; char-displayable-p on a latin1 tty

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: user42_kevin <at> yahoo.com.au, 26396 <at> debbugs.gnu.org
Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty
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.

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

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

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

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.