> Note that the yanked copy is different than the text we copied.  It
> shows up as a '?' character.

I've tracked the bug down to 2 lines in lisp/term/x-win.el:

In x-select-text():
  ;; ICCCM says cut buffer always contain ISO-Latin-1
  (encode-coding-string text 'iso-latin-1)

In x-cut-buffer-or-selection-value():
  ;; ICCCM says cut buffer always contain ISO-Latin-1, but
  ;; use next-selection-coding-system if not nil.
  (decode-coding-string cut-text (or next-selection-coding-system 'iso-latin-1))

So the text we copy is encoded to iso-latin-1 and then decoded again,
which is what is resulting in the corruption.

I've confirmed that replacing iso-latin-1 with windows-1250 in both
places fixes the bug for me (for windows-1250 text, of course).

This ELISP dialog shows how the corruption happens.  I don't know if
the 'e' character will show up correctly in this email, but the
variable czech-e is bound to a string containing a single character,
the czech e-with-a-hook:

ELISP> czech-e
"ì"

ELISP> (string-to-list czech-e)
(331835)

ELISP> (string-to-list (encode-coding-string czech-e 'iso-latin-1))
(63)

ELISP> (string-to-list (decode-coding-string (encode-coding-string czech-e 
'iso-latin-1) 'iso-latin-1))
(63)


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Reply via email to