[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X11 Compound Text vs ISO 2022
From: |
James Cloos |
Subject: |
Re: X11 Compound Text vs ISO 2022 |
Date: |
Thu, 29 Jul 2010 11:51:21 -0400 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
>>>>> "KH" == Kenichi Handa <address@hidden> writes:
KH> Very sorry for the late response on this matter.
That is OK.
KH> I added more
KH> character sets to it for cut&paste between two running
KH> Emacses.
Understood. And, now that you have mentioned it, I think I even
remember (vaguely) a post or a discussion about it from back then.
KH> It's fairly easy to limit charsets of ctext. But, I care
KH> the backward compatibility. As ctext is the only coding
KH> system that is compatible with iso-8859-1 and can encode
KH> many other character sets, there will be old users who still
KH> uses it for file/process encodings.
I was not aware of that.
KH> And, anyway ctext is not used for selection,
I has to be used for X selection, yes? How else could X selection of
text work than using data tagged with X's STRING, COMPOUND_TEXT or
UTF8_STRING atoms?
KH> I'd rather just document that ctext is not fully compatible X's
KH> COMPOUND_TEXT spec, but is the extended vesion.
KH> For WM_NAME, etc, yes, we should use ctext-with-extensions,
KH> and as ctext-with-extensions is not intended to be used
KH> directly by users, I think it won't cause actual problems
KH> even if we change it so that more characters are encoded
KH> using UTF8-extended-segment. So, I'll work on it soon.
ctext-with-extesnions already supports the UTF8 extended segment; the
bug is that it uses JISX 0213 for some characters. The earlier JISX
versions (0201, 0208 and 0212) are OK, but 0213 is not.
KH> The only problem with ctext-with-extensions is that it is
KH> now implemented by Elisp, and thus it may cause GC. I'm not
KH> sure it is safe to call Lisp at the place we convert WM_NAME
KH> etc. If it is not safe, I'll implement
KH> ctext-with-extensions in C.
the WM_NAME code already has to gc protect to do the conversion to utf8
for the gtk call (when compiled for gtk) and the new code to set the
UTF8_STRING _NET_WM_NAME and _NET_WM_ICON_NAME properties; I presume it
could do a conversion to ctext-with-extensions within that same protect?
Then it just needs to prefer utf8 over jisx0213.
Thanks for looking at it.
-JimC
--
James Cloos <address@hidden> OpenPGP: 1024D/ED7DAEA6
- Re: X11 Compound Text vs ISO 2022, (continued)
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/06
- Re: X11 Compound Text vs ISO 2022, Stephen J. Turnbull, 2010/07/06
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, David De La Harpe Golden, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/14
Re: X11 Compound Text vs ISO 2022, David De La Harpe Golden, 2010/07/06
Re: X11 Compound Text vs ISO 2022, Kenichi Handa, 2010/07/29
- Re: X11 Compound Text vs ISO 2022,
James Cloos <=