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

[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 <address@hidden>
> From: Karl Eichwalder <address@hidden>
> 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.



reply via email to

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