[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Display of undisplayable characters: \U01F3A8 instead of diamond

From: Akib Azmain Turja
Subject: Re: Display of undisplayable characters: \U01F3A8 instead of diamond
Date: Fri, 02 Sep 2022 17:47:39 +0600

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>   > Anyway,
>   > I workarounded it by modifying glyphless-char-display with the following
>   > in terminal buffers:
>   > --8<---------------cut here---------------start------------->8---
>   > (set-char-table-extra-slot glyphless-char-display 0 'thin-space)
>   > --8<---------------cut here---------------end--------------->8---
>   > This shows a single space character.  
> Could a variant of that display a diamond instead of a space?

I couldn't find one.  I tried the following, but it didn't work:

--8<---------------cut here---------------start------------->8---
(set-char-table-extra-slot glyphless-char-display 0 "�")
--8<---------------cut here---------------end--------------->8---

It didn't show the diamond (or, in my case, a character similar to a
question mark in inverse video), which is the expected behavior
according to the manual, but it didn't even show the diamond in a box
(or square brackets), instead just a empty box appeared, which is

> Eli wrote
>   > One way of verifying this is to type
>   >    C-x 8 RET fffd RET
>   > in an Emacs session which displays on the Linux console, and see if
>   > that shows the diamond-like glyph or the \Unnnn thing.  If it's the
>   > latter, it means the console doesn't support that character, and we
>   > cannot send its code from Emacs.

How do Emacs know that determine whether a character is supported or
not?  Using the encoding used for output?

> but what is so bad about sending a glyph that the terminal can't
> display?  What bad results does it cause?

As long as the character can be encoded to the encoding the terminal
understand, AFAIK it's fine.  But if the character can't be encoding,
it's impossible, because you don't know how to send it and the terminal
doesn't know how to read it.

> Or how about fixing it by sending an official code for that diamond glyph?

I think it's better.  But the format of glyphless-char-display should be
changed to allow something like the following too, which won't put the
text in a box:

--8<---------------cut here---------------start------------->8---
(set-char-table-extra-slot glyphless-char-display 0 (verbatim . "�"))
--8<---------------cut here---------------end--------------->8---

Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social.

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

Attachment: signature.asc
Description: PGP signature

reply via email to

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