[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: Mon, 17 Apr 2017 11:08:15 +0300

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Sun, 16 Apr 2017 23:41:33 -0700
> Eli Zaretskii wrote:
> > I can offer help in reviewing the patches and perhaps also writing
> > some of that, but I cannot test the code, as I don't have a convenient
> > access to a Linux console where I could run Emacs I build.
> Rather than descend into this swamp I am hoping that the patch I installed is 
> enough to solve Kevin's problem.

I thought we were discussing a broader issue: how to make Emacs work
better on a Linux console, not just how to fix char-displayable-p.

At the very least, I think we should teach Emacs to call
terminal_glyph_code when it decides whether a given character should
be displayed as glyphless or not.  E.g., what do you get on a Linux
console when trying to output a character beyond the BMP, like u+17001
or u+1F800? do you get the expected \uNNNNN representation?  And what
does Emacs display for characters from the BMP that are not supported
by the console's font?

My reading of the code is that at least some of these unsupported
characters will NOT be displayed as \uNNNNN, but rather as some
fallback glyph produced by the console itself, which is not what we
want, I think.


reply via email to

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