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

[Alan Mackenzie]

Hello, Gregory.

On Fri, Sep 02, 2022 at 07:28:51 +0000, Gregory Heytings wrote:

> >
> > I don't see how it could be simpler than using a Linux console, since 
> > that is as simple as could be.  I have 8 of them, and to use one, I just 
> > type the character that switches.
> >

> That won't change.

That is true.

> >
> > ISTR seeing a discussion about whether fbterm "steals characters".
> >

> It doesn't, when configured properly.

Though it has to be said that this configuration is actually disabling
part of fbterm.  It is a hack.

> >> Is there a reason why you cannot (or do not want to?) use fbterm?

> > 1. It will be different
> > 2. I don't have any idea how to use fbterm.
> > 3. I odn't know what new inconveniences it would cause.

> How to install and configure it is documented in efaq.texi (on latest 
> master and emacs-28), around line 3050.  Doing that will take you less 
> time that you've already spent on trying to find a way to change the way 
> Emacs handles nondisplayable characters on Linux consoles.  If you need 
> help, feel free to ask, either here or privately.

> What you'll get is:

> 1. Full UTF-8 support, i.e. no "undisplayable" characters anymore.

Yes.

> 2. 256 colors instead of 8.

Well, actually instead of 16, since all the colours come in a normal and
a bright version.  But these 256 colours will be getting used, and that
means work configuring faces that are not satisfactory to the user in
the 256 colour version.

> 3. Modern fonts instead of pixelated ones.

Here's the rub.  The "pixelated" fonts were designed to be used in, say,
an 8x16 matrix, and work very well indeed.  The "modern" fonts were
designed to be used in X, and work less well in fbterm on a pixelated
grid.

All of the "modern" fonts available for fbterm on my machine are
"spidery" single pixel thick fonts.  On the lat1-16 font I've been using
in consoles for decades, the lines are two pixels thick.  I find this
much more readable.

On some of the fonts I tried, full-frame windows were only 61 rows high
rather than the normal 65.  Some of them were so dark as to be
effectively unreadable.  None of them were really satisfactory.

> There are no known inconveniences.

There are several.  As mentioned above, you have to configure faces,
possibly a lot of them.  There are all the problems with fonts.  You've
got to remember to hack the fbterm binary each time a new version of
fbterm comes out (unless you've got a system like Gentoo, and arrange
for this to happen automatically).

There will likely be people who use an unhacked version of fbterm, with
its key sequences, and they cannot run Emacs on such.  They will
possibly get confused if they need both hacked and unhacked versions of
fbterm together on one machine.

I had problems with fbterm working on my ISP's server over ssh.  The
program at the far end didn't recognise TERM=fbterm and gave up.  I had
to call ssh as $ TERM=linux ssh .... to get it to work.

There are lots of itty-bitty things you've got to get used to to use
Emacs in fbterm, and it is more inconvenient than the plain Linux
console where you need merely to log on and type $ emacs.

Likely there will be more little problems with fbterm turning up.

I will probably continue using the plain Linux console, for all these
reasons.

I agree with Richard that there should be an option for displaying
characters outside of the current font as "�" rather than "\u2022".  It
is a feature of the Linux console that all such characters are displayed
that way.  There is no possibility of any character causing an undefined
action.

-- 
Alan Mackenzie (Nuremberg, Germany).