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

[Alan Mackenzie]

Hello, Eli.

On Sun, Aug 28, 2022 at 13:29:13 +0300, Eli Zaretskii wrote:
> > Date: Sun, 28 Aug 2022 10:07:00 +0000
> > Cc: rms@gnu.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > Can we modify info.el so as to display those characters
> > > > as the curresponding ASCII punctuation characters?

> > > It already does, where an ASCII equivalent exists.  See
> > > info-symbols-and-replacements.  Alan didn't report any details, so I
> > > don't have any idea why it doesn't work for him (if indeed it doesn't).

> > I didn't actually know about that feature, which you added in October
> > 2019 (commit 8dd18bbb6f3c09a4988cf2e06378aa24b098fb85).  It fails on my
> > Linux console because of a guarding clause in the `unless' which
> > surrounds the initialisation of buffer-display-table:

> >   (unless (or (display-multi-font-p)
> >               (coding-system-equal                 <====================
> >                (coding-system-base (terminal-coding-system)) <==========
> >                'utf-8))                            <====================
> >     (dolist (elt info-symbols-and-replacements)
> >       (let ((ch (car elt))
> >             (repl (cdr elt)))
> >         (or (char-displayable-p ch)
> >             (aset (or buffer-display-table
> >                       (setq buffer-display-table (make-display-table)))
> >                   ch (vconcat (mapcar (lambda (c)
> >                                         (make-glyph-code c 'homoglyph))
> >                                       repl)))))))

> > On my setup that (coding-system-equal .... 'utf-8) returns t, so
> > buffer-display-table never gets initialised.

> > Why is that coding-system-equal form there?

> It was written based on the assumption that a terminal that supports
> the UTF-8 encoding can also display the original characters reasonably
> enough.  Are you saying that the Linux console lies about that, and
> those characters are displayed as hex codes?

Well, I think "lies" is a bit strong, here.  The Linux console uses UTF-8
characters, but is restricted to an arbitrary selection of 256 of them.
An attempt to display any other character on the screen gets \ufffd
displayed instead.  Possibly, double-width characters aren't correctly
handled, I don't know.  My console is configured to use Latin-1, and it
also includes some line graphic characters, but not the punctuation
characters used by makeinfo.

Those characters were indeed displayed as hex codes, until I applied the
patch below.

> If so, please try the patch below.

> diff --git a/lisp/info.el b/lisp/info.el
> index 739116c..5655e3f 100644
> --- a/lisp/info.el
> +++ b/lisp/info.el
> @@ -4446,9 +4446,12 @@ Info-mode
>    (setq buffer-read-only t)
>    (setq Info-tag-table-marker (make-marker))
>    (unless (or (display-multi-font-p)
> -              (coding-system-equal
> -               (coding-system-base (terminal-coding-system))
> -               'utf-8))
> +              (and (coding-system-equal
> +                    (coding-system-base (terminal-coding-system))
> +                    'utf-8)
> +                   ;; The Linux console has limited character
> +                   ;; repertoire even when its encoding is UTF-8.
> +                   (not (equal (tty-type) "linux"))))
>      (dolist (elt info-symbols-and-replacements)
>        (let ((ch (car elt))
>              (repl (cdr elt)))

This works for me.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).