Re: Cut buffers and character encoding

[Kenichi Handa <handa@m17n.org>]

In article <45542D63.5070402@swipnet.se>, "Jan D." <jan.h.d@swipnet.se> writes:

> Romain Francoise skrev:
> > "Jan D." <jan.h.d@swipnet.se> writes:
> > 
>>> The text encoding for cut buffers are defined to be ISO-Latin-1, so
>>> selection-coding-system should not have any effect.  That said, we
>>> could decode data from cut buffers from Latin-1 and encode to Latin-1
>>> when putting data in there.
> > 
> > Ah, thanks, you put me on the right track.
> > 
> > Emacs *does* decode the contents of the cut buffer in the
> > `x-cut-buffer-or-selection-value' function, but it tries to decode them
> > using `locale-coding-system' which is wrong if the locale is a UTF-8
> > locale...
> > 
> > The following patch fixes the problem for me, and if cut buffers are
> > *always* iso-latin-1 then it should be the right thing.  WDYT?

> I've committed this change and the corresponding when writing to a cut buffer.
> I also changed the documentation you pointed out was wrong.

I vaguely remember that I changed cut-buffer decoding to use
locale-coding-system (if any) instead of iso-8859-1 upon a
bug report from someone.  He claimed that many X
applications store a data encoded by the current locale in
cut-buffer (even if that doesn't conform to ICCCM), thus it
is better that Emacs also decodes it by the coding system
specified by the locale.  Even xterm, when run under, for
instance, cs_CS.ISO8859-2 locale, stores ISO8859-2
characters as is in cut buffer.

In the case of the origianl bug report, "éèê" is actually
tried to be decoded by utf-8 and failed.

Anyway, the documentation bug of selection-coding-system
should be fixed.  But, it may be good to use
next-selection-coding-system even for cut buffer if it is
set temporarily by C-x RET X.

---
Kenichi Handa
handa@m17n.org