[Top][All Lists]

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

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

From: Alan Mackenzie
Subject: Re: character sets as they relate to “Raw” string literals for elisp
Date: Tue, 5 Oct 2021 11:20:47 +0000

Hello, Daniel.

On Mon, Oct 04, 2021 at 15:19:22 -0700, Daniel Brooks wrote:
> 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

Indeed, yes.  ;-)

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

So, you've set up your keyboard specially to be able to type these things
easily.  I think we can be sure that a lot of your readers won't have
done the same.  I've set up mine to be able to type ä, Ä, ö, Ö, ü, Ü, and

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

OK.  If the kernel's console also had the same range of characters, would
you then use that console for text work?

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

Exactly so.  The Linux console code is exceptionally old gnarled code,
which is difficult to work with.  (I know, having recently hacked it to
restore "soft scrolling" via the S-<PgUp>, S-<PgDn> keys.)

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

Actually, no it's not.  I had to hack its source a few years ago to be
able to configure C-A-S-Fn in X.  The corresponding program for the
console, loadkeys, can pretty much do anything.

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

Actually, if it was an optional feature, I think it would be welcome in
the kernel, although most kernel hackers would probably continue not to
use it.  2 or 3 Mb isn't a large amount of RAM on a desktop machine any

> db48x

Alan Mackenzie (Nuremberg, Germany).

reply via email to

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