GNU bug report logs -
#26396
25.1; char-displayable-p on a latin1 tty
Previous Next
Full log
Message #65 received at 26396 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 8 years and 66 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.