emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: can't paste non-Latin-1 text to Emacs 21.2


From: Dave Love
Subject: Re: can't paste non-Latin-1 text to Emacs 21.2
Date: Thu, 01 Apr 2004 19:51:22 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Kenichi Handa <address@hidden> writes:

> Although "Č" in your mail arrived at me as charset
> iso-8859-4, and thus it can succcessfully pasted into 21.2,
> perhaps what you did was to paste mule-unicode-0100-24ff
> character into 21.2, right?

I meant to say I'd pasted it from HELLO as Latin-2, but I realize that
HELLO was messed up somehow, so please ignore it.  It does work with
Latin-2, and I'm surprised what I posted came out as 8859-4.  It looks
as though I wasn't all awake when I sent that, and should have checked
the text.

> Then, yes, the latest code encodes such a character by using
> ESC % G ... ESC % @ (XFree86 extension for UTF-8 encoding)
> because that is more widely accepted with the other clients
> than ESC $ - 1 ... (designating the private charset
> mule-unicode-0100-24ff) even though 21.3 and the prior
> doesn't recognize it.

More to the point, it violates the X consortium definition of CTEXT
(sigh) although Emacs never got it right either for private charsets.

> This behaviour is controlled by the
> function ctext-non-standard-encodings-table.

This doesn't seem to be in NEWS.  Shouldn't it be controlled by a
variable (user option)?  The correct thing to do with text you can't
encode with standard ISO2022 charsets appears to be to use an extended
segment labelled as, say, utf-8.  That's correct and unambiguous as
long as you use IANA names.  I did once at least start to implement
that, but I don't remember if I finished.

> Another idea is to encode such characters to some of legacy
> charsets that are listed as "Approved Standard Encoding".

I don't think you should restrict it to the explicit list, if that's
what you mean.  It seems fairly clear that ISO standard charsets
should get normal ISO2022 encoding in CTEXT.  (I couldn't find a
current address for Scheifler to check the unsupported assertion
that's wrong.)  I'm sure Emacs should try to translate characters from
private charsets to standard ones for ctext unless it can tell that
the selection is for another Emacs client.

> I'll put it in my todo list.  I would appreciate if you or
> someone else can work on it.

I definitely won't.




reply via email to

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