Bram Moolenaar wrote: > SungHyun Nam wrote: > >>>> Yuriy Kaminskiy wrote: >>>>> SungHyun Nam wrote: >>>>>> 2010-09-23 AM 12:49, Young Ho Park wrote: >>>>>>> Hello. I am a Vim user from South Korea. I seem to find the bug about >>>>>>> cut(or copy) and paste. Let me explain steps to a paste fail. >>>>>>> >>>>>>> I use Vim7.2 in Gnome2.3 of Fedora13 or Ubuntu10.04 and my locale is >>>>>>> ko_KR.utf8 0. I executed Vim. 1. I wrote Alphabet and Hangul mixed >>>>>>> string. 2. I clicked a copy(or cut) button. 3. I closed Vim. 4. I >>>>>>> executed Vim again. 5. I clicked a paste button. 6. English >>>>>>> characters were well copied. But Hangul characters are changed to >>>>>>> question marks like: =BF?=BF?=BF?=BF? >>>>>>> >>>>>>> Is it a bug? Or didn't I turn on some options? >>>>>> More info about this problem. >>>>>> >>>>>> 1. If I don't quit select&copied-gvim, then paste to >>>>>> gnome-terminal or other-gvim works fine. >>>>>> >>>>>> 2. If I quit select&copied-gvim: >>>>>> o paste menu in gnome-terminal became disabled (and nothing >>>>>> happened if I click middle mouse button). >>>>>> o when I paste in other-gvim, hangul characters are now >>>>>> corrupted. >>>>> I think this was introduced in 7.2.221 patch, that tries a bit >>>>> too much to follow standard on CUTBUFFER* encoding, rendering it >>>>> useless for any non-latin1 locales. >>>> I revert 7.2.221 patch [*1*] and the corrupt problem gone. >>>> >>>> With a reverted gvim-gtk2, >>>> >>>> 1. If I don't quit select&copied-gvim, then paste to >>>> gnome-terminal or other-gvim works fine. >>>> >>>> 2. If I quit select&copied-gvim: >>>> o paste menu in gnome-terminal became disabled (and nothing >>>> happened if I click middle mouse button). >>>> * PASTE IN OTHER-GVIM WORKS FINE (NO CORRUPTION). >>> The cut buffer is a very old mechanism and should not be used for any >>> modern program. See http://www.jwz.org/doc/x-cut-and-paste.html They >>> are still provided for compatibility with old programs, and these are >>> expected to only use latin1. >>> >>> The problem is that when Vim exits the contents of the selection and >>> clipboard are lost. The text is put in the cut buffer as a last resort. >>> Not only does this drop the encoding, also other properties are lost >>> (e.g. blockwise selection). >>> >>> One could think of a hack, such as a magic string at the start of the >>> buffer that encodes the meta data. But the result is that pasting in >>> another application produces a mess. >>> >>> The only good solution is to not exit Vim. Or use some kind of >>> clipboard manager that consumes the text and mimics Vim when it has >>> exited. >> How about acting like gnome-terminal? >> I mean 'no paste' for such a case. > > Hmm, we could do something special when the conversion from 'enc' to > latin1 has errors. Then we know that pasting won't produce something > useful.
What application expect CUTBUFFER0 exclusively in latin1? And won't accept vim using *current encoding* for CUTBUFFER0, as it was before 7.2.221? (and after all, if someone seek interoperability in such case, he can just run gvim in with in latin1 locale; with 7.2.221 there are no recourse at all) One more alternative - use *current locale encoding*. Of course, using current locale encoding won't work *always* (e.g. if we run gvim in one locale, xterm in other, exit from gvim and then paste in xterm). However, in most cases naive approach would work with less borkage. -- 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
