[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: Sat, 15 Apr 2017 14:12:40 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

Eli Zaretskii wrote:
So, the plan seems to be this:

  . make sure the terminal is in Unicode mode,

I don't think we need to worry about whether the console is in UTF-8 mode. UTF-8 mode has been the default for years, and unless the user goes to a good deal of trouble (and I suspect this part of the Linux kernel hasn't been tested recently) we can assume UTF-8 mode.

There is a subtlety here. The console can be in UTF-8 mode for input ('stty iutf8' vs 'stty -iutf8'), but that's not what we're concerned about: we're concerned whether it's in UTF-8 mode for output. I don't see how the user can affect the latter other than by outputting ESC % @ and ESC % G. And I just now tried outputting these sequences to my Linux console but they didn't seem to affect anything. Without the ability to test this stuff and with no real need to worry about it that I can see, I suggest that we just assume UTF-8 mode.

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. Certainly set-locale-environment should not override the fact that Emacs is connected to a Linux console. (You mention this below.)

  . if a character has a glyph in the Unicode font, send a UTF-8
    encoding for the character to the screen, disregarding the
    terminal encoding as mandated by the locale
  . if the character doesn't have a glyph in the console font, treat
    it as glyphless

This sounds right.

  . if the conditions in the first item above are not met, fall back
    to the current code which encodes using the terminal encoding

As I mentioned above, perhaps we should not worry about those conditions and therefore not worry about falling back to the current code.

I notice that we don't use terminal_glyph_code when determining
whether a given character should be treated as glyphless, so I guess
that means we could produce something other than what
glyphless-char-display says for a given character; this should be

Sorry, I am not quite following this, but yes the various parts of Emacs should be consistent in this area.

Also, the above means set-locale-environment should not call
set-terminal-coding-system if the display is a Linux console that
supports this feature.

This matters only if we worry about the terminal coding system in Linux consoles, which it isn't clear we should do.

reply via email to

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