Loading ...
Sorry, an error occurred while loading the content.

Re: Bug in clipboard support with multibyte charactors?

Expand Messages
  • Yue Wu
    ... Yes, it s opera! ... 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
    Message 1 of 5 , Dec 4, 2010
    View Source
    • 0 Attachment
      On Sat, Dec 04, 2010 at 12:36:39PM +0300, ZyX wrote:
      > 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.

      >
      > 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:
      > > In vim on xterm, yanking string that have multibyte charactors then
      > > 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 root@...
      > > 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

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • James Vega
      ... 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
      Message 2 of 5 , Dec 4, 2010
      View Source
      • 0 Attachment
        On Sat, Dec 04, 2010 at 04:28:07PM +0800, Yue Wu wrote:
        > 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 <jamessan@...>
      • ZyX
        Reply to message «Re: Bug in clipboard support with multibyte charactors?», sent 18:30:24 04 December 2010, Saturday ... It is not related to cut buffer:
        Message 3 of 5 , Dec 4, 2010
        View Source
        • 0 Attachment
          Reply to message «Re: Bug in clipboard support with multibyte charactors?»,
          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.
        Your message has been successfully submitted and would be delivered to recipients shortly.