[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: Yuri Khan
Subject: Re: character sets as they relate to “Raw” string literals for elisp
Date: Tue, 5 Oct 2021 15:55:46 +0700

On Tue, 5 Oct 2021 at 03:51, Daniel Brooks <db48x@db48x.net> wrote:

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

fbterm already provides at least basic Unicode support. As in, it is
not limited to displaying 256 or even 512 characters, and it uses
libfreetype to draw glyphs. I have not tested whether it supports
complex text shaping or color emoji.

(It is not a kernel module, just a normal userspace binary talking to /dev/fbN.)

[By the way, you’re hypercorrecting a little bit. “full-featured” and
other hyphenated words are not normally spelt with an en dash. From

    In English, an en dash, –, sometimes replaces the hyphen
    in hyphenated compounds if either of its constituent parts
    is already hyphenated or contains a space (for example,
    San Francisco–area residents, hormone receptor–positive cells,
    cell cycle–related factors, and public-school–private-school


reply via email to

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