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

[Daniel Brooks]

Alan Mackenzie <acm@muc.de> 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?
>
> It does for me.

Aha! I’m rather astounded that this is the case, but happy to know that
we are talking about a use–case that actually affects real users, as
opposed to merely hypothetical ones. Thank you!

>> 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.

You are making unwarranted assumptions about my keyboard :D

But alas, it’s fairly ordinary; I don’t actually have the keyboard of my
dreams. Instead, there are some xkb options that I turn on to make it
more capable. To type a ｢"｣ I have to press S-', while to type ｢“｣ I
press Level3-k; it’s a different pair of fingers, but not really any
more difficult or awkward to type.

> 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?

I use a GUI precisely because the range of characters is so much wider,
making the text work more fun. Also, because the fonts aren’t blurry to
me, ever since I adjusted the font hinting slightly and bumped up the
minimum font sizes significantly (I agree that blurriness is somewhat
subjective).

>> (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.

Yea, that’s why I said that it would need to be statically linked. The
console already uses the framebuffer, it just needs support for reading
TTF fonts (libfreetype) and shaping the text properly (libharfbuzz). I’m
sure some other handwavium would be needed too, but in principle there’s
no reason the Linux console shouldn’t be able to completely support
Unicode text display. It’s just that nobody has done the work.

Of course I hadn’t been thinking of input handling, but xkb does already
exist. While it is a problem that the name starts with an ‘x’, the core
logic of translating keycodes into characters via a keymap is all
there. Presumably with sufficient elbow grease the X protocol stuff
could be filed off and the important bits reused.

I can hear the laughter already, as we propose adding a 2 or 3 megabyte
kernel module. It would be hilarious. Can you imagine it now?

db48x