Bram Moolenaar wrote: > Yuriy Kaminskiy wrote: > >> 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? > > Xterm at least.
Hmm. Funny. *Works* for me with LANG=ru_RU.KOI8-R (xterm-222, xterm-262, rxvt-unicode 9.07, gvim/gtk2 7.2.218). ...and does NOT work with LANG=ru_RU.UTF-8 :-| One more example of how code overcomplication based on us-ascii-only-minded standard breaks things :-| Anyway, attempt to convert it to/from latin1 will break it too (attempt to convert it to latin1 will fail, so it will save it in *utf-8*, and converting it back *from latin1* will "appear working", but produce mojibake). >> 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*. > > "current encoding" is internal to Vim, it's unlikely other applications > know about it. Using the "system encoding" would make more sense. Yep, current encoding is internal. However, it is most likely will be same as system encoding. That is, using system encoding is slightly more correct, but I'm not sure it overweight code complication. > But it wouldn't work when that encoding is latin1 or another 8-bit > encoding. Of course, you cannot do miracle - with no way to specify encoding there are no way cutbuffer will work with *mixture* of encodings. I only want *not break what will work naturally* - i.e. between application using same locale. >> 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. > > But there will be situations where it breaks. Which then would result > in yet another option to switch it off. When it will break, blindly converting to latin1 will be no better. (it will work only in one case: if your system encoding is latin1; but if you have mixture of encodings, you already have some *non*-latin1 encodings in mix, and it *won't* work). -- 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
