|
From: | Paul Eggert |
Subject: | bug#26396: 25.1; char-displayable-p on a latin1 tty |
Date: | Sun, 16 Apr 2017 13:25:42 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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-systemIt 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.
[Prev in Thread] | Current Thread | [Next in Thread] |