[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cut from xterm (iso-8859-{2,15}) and paste into buffer
From: |
Eli Zaretskii |
Subject: |
Re: Cut from xterm (iso-8859-{2,15}) and paste into buffer |
Date: |
Sat, 17 Nov 2001 09:59:02 +0200 |
> Reply-To: Karl Eichwalder <keichwa@gmx.net>
> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Fri, 16 Nov 2001 21:05:55 +0100
>
> Produce an iso-8859-2 string:
>
> LANG=cs_CZ.iso-8859-2 cp --version | head -2
> => cp (fileutils) 4.1
> Auto(r)i: Torbjorn Granlund, David MacKenzie, and Jim Meyering.
> ^^^8bit! An "r" with a caret turned upside down.
>
> Paste it in an Emacs buffer prepared for iso-8859-2:
>
> LANG=cs_CZ.iso-8859-2 emacs -q --no-site
>
> The '(r)' is printed as an iso-8859-1 character: "(/o)".
What is your value of selection-coding-system in that session?
> Another problem is to paste from an iso-8859-15 xterm into an
> iso-8859-15 (Latin-9) enabled buffer. 8bit characters are obeyed but
> "prefixed" with encoding information:
>
> ^[%/1\200\214iso8859-15^B("o)
> ^^ ^^^^^^^^ ^^
> All parts marked with "^^" are transliterated by me
Same question as above.
Do you happen to know what exactly does Emacs get as the raw string
from the X selection, before it decodes it? One way to find out is
to step with a debugger through the function
selection_data_to_lisp_data (defined on xselect.c), and print the
string that is being decoded.
The reason I'm asking is that some X programs are known to produce
invalid strings in selections; Emacs uses strict adherence to the
standard, and thus doesn't cope well with those cases.