Bug in clipboard support with multibyte charactors?
Yue Wu
paste into other GUI apps will make the string garbled. Say I have
测试
in file, yank it into "* and "+ and paste into browser will get the
weird string:
o$(A2bJT
But paste into xterm itself fine.
Typing "测试" directly in xterm outside vim then yank it with mouse
will be fine when paste it into other GUI apps.
I also notice, the yanking is fine for xterm, but after leaving vim, the string
will become garbled even when paste in xterm.
When copy charactors from other GUI apps, paste into vim with middle mouse click will be ok, but with "* or "+, string becomes garbled for multibyte charactors.
OS: 8.1-STABLE
vim version:
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Dec 4 2010 12:01:37)
Included patches: 1-62
Compiled by ro...@fbsd.t60.cpu
Big version without GUI. Features included (+) or not (-):
+arabic +autocmd -balloon_eval -browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments +conceal
+cryptv +cscope +cursorbind +cursorshape +dialog_con +diff +digraphs -dnd -ebcdic
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path +float
+folding -footer +fork() +gettext -hangul_input +iconv +insert_expand +jumplist +keymap
+langmap +libcall +linebreak +lispindent +listcmds +localmap -lua +menu +mksession
+modify_fname +mouse -mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm
+mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg -osfiletype
+path_extra -perl +persistent_undo +postscript +printer -profile -python -python3
+quickfix +reltime +rightleft -ruby +scrollbind +signs +smartindent -sniff +startuptime
+statusline -sun_workshop +syntax +tag_binary +tag_old_static -tag_any_white -tcl
+terminfo +termresponse +textobjects +title -toolbar +user_commands +vertsplit
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore +wildmenu +windows
+writebackup +X11 +xfontset -xim +xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -I/usr/local/include -O2 -pipe -march=pr
escott -fno-strict-aliasing -march=prescott -D_FORTIFY_SOURCE=1 -I/usr/local/include
Linking: cc -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -Wl,--as-needed -o vim
-lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -ltermlib -liconv -lintl
--
Regards,
Yue Wu
Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China
ZyX
sent 11:28:07 04 December 2010, Saturday
by Yue Wu:
Let me guess: browser is Opera? I filed them a bug (DSK-318975) because first
after Opera moved to a new engine, pasting from vim got spoiled. After I updated
vim to 7.3 pasting to vim got spoiled as well. Workaround: use `xclip'.
xclip -o | xclip -i
and things work fine again.
It will be good if you file this bug again at http://bugs.opera.com/wizard: as
bugtracker is not public, you should not have known that somebody reported it,
but posting a duplicate will make this bug have a bit higher priority.
Original message:
Yue Wu
> Reply to message «Bug in clipboard support with multibyte charactors?»,
> sent 11:28:07 04 December 2010, Saturday
> by Yue Wu:
>
> Let me guess: browser is Opera? I filed them a bug (DSK-318975) because first
Yes, it's opera!
> after Opera moved to a new engine, pasting from vim got spoiled. After I updated
> vim to 7.3 pasting to vim got spoiled as well. Workaround: use `xclip'.
> xclip -o | xclip -i
> and things work fine again.
But the weired thing is that, xterm works fine in these conditions,
just vim doesn't, so I suspect it's vim relative, not xterm and opera.
--
James Vega
> I also notice, the yanking is fine for xterm, but after leaving vim, the string
> will become garbled even when paste in xterm.
This is due to the way that copy/pasting works in X. When you copy
something, the applications just flags itself as "owning" the clipboard
("*) or primary ("+) selection. When you paste, the application
receiving the paste checks whether any other application has claimed
ownership of the proper selection and, if so, requests that application
to provide the copied text.
If you close the application which performed the copy, then there's no
way to request that text from it. So some applications, like Vim and
xterm, will also store the copied text into a deprecated facility called
a cut buffer when they lose ownership of the selection (like when they
quit). The problem here is that the cut buffer MUST be latin1 encoded.
Long story short, if you want non-lossy cut/paste then leave Vim open
until after you paste. Alternatively, install a clipboard manager (such
as glipper or klipper) which monitors for ownership and immediately
requests the contents of the copied text from the asserting
application. You can also use a more manual tool like xclip to achieve
the same effect.
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>
ZyX
sent 18:30:24 04 December 2010, Saturday
by James Vega:
> If you close the application which performed the copy, then there's no
> way to request that text from it. So some applications, like Vim and
> xterm, will also store the copied text into a deprecated facility called
> a cut buffer when they lose ownership of the selection (like when they
> quit). The problem here is that the cut buffer MUST be latin1 encoded.
It is not related to cut buffer: neither Opera nor vim are closed. And it seems
like vim 7.3 is no longer using cut buffer.
> Long story short, if you want non-lossy cut/paste then leave Vim open
> until after you paste. Alternatively, install a clipboard manager (such
> as glipper or klipper) which monitors for ownership and immediately
> requests the contents of the copied text from the asserting
> application. You can also use a more manual tool like xclip to achieve
> the same effect.
Using clipboard manager (klipper) for some reason fixes only vim->Opera pasting,
not the opposite. Using xclip fixes pasting in both directions.