Christian Brabandt wrote: > Hi Praful! > > On Do, 29 Mai 2014, Praful Kapadia wrote: > > > I have had an annoying issue with gvim 7.4, with patches 1-307. If I > > open a large file (e.g. containing 200,000 lines) and use the global > > command to delete lines, the operation takes a very long time on > > Windows if clipboard has been set to unnamed. I'm assuming it's the > > constant copying of deleted lines to the Windows clipboard that's > > slowing gvim down. > > > > I use Windows 7 64-bit. I have compiled gvim 64-bit using ming. The > > issue occurs on gvim 64-bit, 32-bit and, to a lesser extent, on > > MacVim. > > > > On Windows, it takes several minutes to carry out the operation. > > During this time, Windows becomes unusable, which is poor but that's > > another issue. > > > > On OS X, in MacVim, the same operation takes 30 seconds. With > > clipboard="", it takes two seconds. > > > > Here are the steps to reproduce the issue: > > > > 1. Open gvim with no plugins and no vimrc. > > 2. :set clipboard=unnamed > > 3. Open a text file with about 200,000 lines. > > 4. Enter :g/string/d The "string" should match about 150,000 lines > > i.e. you want to delete lots of rows! > > 5. Go for a coffee break (Windows!) or wait 30 seconds (OS X) > > > > In practice, if I issue the command on Windows, I kill the process then > > open the file again, this time setting clipboard="" before I issue the > > command. > > > > The workaround (:set clipboard="") is fine if you remember it! It > > would be nice if gvim did this e.g. (pseudo-code): > > > > old_clipboard = clipboard > > try > > clipboard = "" > > execute global command > > finally > > clipboard = old_clipboard > > end > > > > One consideration for side effects: currently, if clipboard=unnamed, > > the only text that ends up on the system clipboard is the final > > deleted line, not all deleted lines. If anything, you might want all > > deleted text to be on the clipboard but that is not what currently > > happens. I suspect neither the last line nor all lines is generally > > required. I don't care (others might) what ends up on the clipboard > > and would be happy if there was no speed penalty when the command > > was issued! > > > > It would be great if someone could look at this! > > This is a known issue for windows (see :h todo.txt and search for > :g/test/d) > > Here is an experimental patch, that resets the clipboard option for :g > command, when there are many matches (>100). Note: I haven't tested it.
I wonder if this only applies to the :g command. Doesn't :%s have the same problem? And perhaps joining many lines. Anything that repeatedly puts text in the " register. Wouldn't it be possible to postpone putting text on the clipboard until a command has finished? It's like settint the 'clipboard' option empty and restoring it, and when it's restored to the copy to the clipboard. Perhaps set a flag "postponed_clipboard_set" and handle it in the main loop. Not sure if there are exceptions (e.g., fetching the clipboard halfway the command). -- hundred-and-one symptoms of being an internet addict: 238. You think faxes are old-fashioned. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
