[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding of etc/HELLO
From: |
Juri Linkov |
Subject: |
Re: Encoding of etc/HELLO |
Date: |
Mon, 23 Apr 2018 23:05:08 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
>> I don't understand why it's impossible to create a charset like the
>> existing mule-unicode-e000-ffff but for character range over U+FFFF
>> to include such characters as U+1F44B. Or is this an inherent limitation
>> of the iso-2022-7bit coding system?
>
> I'm not sure I understand your proposal. Are you suggesting to create
> a Mule charset covering just the Emoji block? That could be possible
> (assuming ISO-2022 still has vacant charset slots available, something
> that I don't think I know how to determine reliably, and assuming we
> decipher the black art of using define-charset). But is this worth
> doing it just for Emoji?
>
> If you mean to add a larger range of characters, then I think a single
> ISO-2022 compatible charset can support at most 8192 character, so we
> will need a lot of charsets to cover codepoints between U+10000 and
> U+2FFFF, and I'm not sure we have that many vacant slots.
>
> Or did you mean to suggest something else?
This is exactly what I meant. While using ISO-2022 encoding in HELLO
to represent Unicode characters is just an inconvenience, the inability
to encode all Unicode characters in ISO-2022 is a serious limitation.
- Re: Encoding of etc/HELLO, (continued)
- Re: Encoding of etc/HELLO, Eli Zaretskii, 2018/04/21
- Re: Encoding of etc/HELLO, Paul Eggert, 2018/04/21
- Re: Encoding of etc/HELLO, Stefan Monnier, 2018/04/22
- Re: Encoding of etc/HELLO, Eli Zaretskii, 2018/04/23
- Re: Encoding of etc/HELLO, Stefan Monnier, 2018/04/23
- Re: Encoding of etc/HELLO, Eli Zaretskii, 2018/04/23
Re: Encoding of etc/HELLO, Paul Eggert, 2018/04/20