GNU bug report logs - #26396
25.1; char-displayable-p on a latin1 tty

Previous Next

Full log

Message #29 received at 26396 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: user42_kevin <at> yahoo.com.au, 26396 <at> debbugs.gnu.org
Subject: Re: bug#26396: 25.1; char-displayable-p on a latin1 tty
Date: Thu, 13 Apr 2017 10:16:21 +0300

> Cc: 26396 <at> debbugs.gnu.org
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 12 Apr 2017 23:19:53 -0700
> 
> Eli Zaretskii wrote:
> > I think the code in
> > char-displayable-p which looks at the result of internal-char-font
> > should only accept a non-negative value if the terminal-coding-system
> > supports the character.  IOW, the Linux console should not be
> > considered as being able to display a character unless the terminal
> > encoding can safely encode it.
> 
> Wouldn't it be better if Emacs ignored terminal-coding-system when the output 
> device is a Linux console and Emacs therefore knows exactly which characters the 
> console can display? Instead, Emacs could simply display those characters as-is. 

Yes, that would be better.  But it's probably a non-trivial project,
since we'd need separate code to determine double-width glyphs,
padding glyphs, and perhaps also something special for composed
characters.  Does the Linux console allow us to figure out all of
that?

And what does "display as-is" means in practice?  Should we send to
the console the glyph codes corresponding to Unicode points, or should
we send UTF-8 encoded characters?  (Is there some document which
describes these features in enough detail for us to figure out their
implications on Emacs display code?)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.