[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]