Re: character sets as they relate to “Raw” string literals for elisp

[Alan Mackenzie <acm@muc.de>]

Hello, Daniel.

On Mon, Oct 04, 2021 at 13:49:53 -0700, Daniel Brooks wrote:
> Eli Zaretskii <eliz@gnu.org> writes:

> >> From: Daniel Brooks <db48x@db48x.net>
> >> Cc: emacs-devel@gnu.org,  rms@gnu.org,  anna@crossproduct.net
> >> Date: Mon, 04 Oct 2021 08:36:40 -0700

> >> Eli Zaretskii <eliz@gnu.org> writes:

[ .... ]

> >> PS: it occurs to me to wonder if my use of Unicode in the prose of this
> >> message, outside of the examples, detracted from its readability in any
> >> way?

> > If someone is reading this on a text-mode terminal, it could.

It does for me.

> I am asking if anyone reading my messages, either this one or any of the
> last dozen I have sent to the list, have noticed any specific
> problems. I have used non–ascii characters in all of them. I’m wondering
> if anyone even noticed. If nobody noticed, or if they didn’t detract
> from readability, then it is unlikely that Unicode is a problem in
> general.

These characters displayed as inverse question marks on my Linux console.

I can understand people wanting their non-ascii names to be properly
spelt (just as I prefer my non-ascii home city Nürnberg to be correctly
spelt).

What I don't really understand is including punctuation characters which
can't be typed on the writer's keyboard, except by awkward workarounds.

> Yuri Khan <yuri.v.khan@gmail.com> writes:

> > On Tue, 5 Oct 2021 at 01:58, Eli Zaretskii <eliz@gnu.org> wrote:

> >> If someone is reading this on a text-mode terminal, it could.

> > We should probably invent a term more accurate than “text-mode
> > terminal” for things that fail to display text.

> True! :D

> I prefer to say “Linux console” in reference to the one terminal
> emulator that we know has severe problems with Unicode. There are many
> terminal emulators out there, and I’m sure a few of them have problems,
> but for the most part I think all of them can handle Unicode pretty well
> primarily because they all rely on OS libraries to do the heavy
> lifting. The Linux console is handicapped in this area primarily because
> it is inside the kernel, and thus cannot dynamically load libharfbuzz
> and libfreetype.

One of the reasons I use Linux is because I have a 16 x 8 dot fontset,
and don't have to cope with all the vagaries of fancy, sometimes blurred,
fonts used on GUIs.  There are quite a few others.  Why use a graphical
environment for doing text work?

> (But I can imagine a hypothetical future kernel module which statically
> links against them in order to provide a full–featured terminal in the
> console.)

I can't.  The Linux console has got to work to bring up a new machine,
should one be doing this from scratch rather than installing a
distribution with ready made X.  For this, it's _got_ to work directly in
the kernel.

> db48x

-- 
Alan Mackenzie (Nuremberg, Germany).