[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: Eli Zaretskii
Subject: bug#26396: 25.1; char-displayable-p on a latin1 tty
Date: Sat, 15 Apr 2017 11:48:15 +0300

> > Suppose we only wanted to use this feature for UTF-8 locales.
> > Assuming that the OS takes care of putting the console in UTF-8 mode,
> > we don't need any changes in Emacs, since Emacs already sends UTF-8
> > sequences to the screen driver.  As the Linux console only supports
> > the BMP, we could then simply amend the code of char-displayable-p to
> > check whether a character is within the BMP, when the terminal is the
> > Linux console.  Do you agree with this conclusion?
> No, because a character is displayable only if it's in that set of 
> at-most-512 characters.
> > OTOH, now I'm not sure I understand the need for terminal_glyph_code.
> > What does it do that a simple check for a Linux console and UTF-8
> > terminal encoding, plus a character being inside a BMP, don't?
> terminal_glyph_code gets the current set of at-most-512 displayable 
> characters from from the kernel.

Right, I missed the 512-character part.  Quite a limitation, btw.

So, the plan seems to be this:

  . make sure the terminal is in Unicode mode, and that the user
    didn't override by a call to set-terminal-coding-system
  . 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
  . if the conditions in the first item above are not met, fall back
    to the current code which encodes using the terminal encoding

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

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.

Is that right?

reply via email to

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