Hi Christian, On 2014-05-31, Christian Brabandt wrote: > Hi Gary! > > On Fr, 30 Mai 2014, Gary Johnson wrote: > > > On 2014-05-30, 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. > > > > [...] > > > > > This is a known issue for windows (see :h todo.txt and search for > > > :g/test/d) > > > > I have seen a related problem, if not the same problem, running vim > > 7.4.283 in an xterm on Fedora 17. > > > > While editing a file of about 50k lines, I put the cursor on a line > > a few tens of lines from the bottom of the file and executed dgg. > > When I then tried moving the cursor a few lines lower, it moved in > > response to the first few j commands, then vim locked up for about 5 > > minutes.
[...] > > > 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. > > > > If this is the same problem, then fixing it for :g/teset/d doesn't > > address the other cases of deletion such as dgg. > > Yes, it wouldn't fix it for your case. Your use case looks really awful. > Are other applications as slow? I am not sure, we could do anything for > you. Perhaps it would be possible to disable the clipboard, if it takes > too long updating it? Why are you setting your clipboard to unnamed, if > it works so slow? The speed of applications running on the Linux machine in this setup varies. Coworkers have commented on the sluggishness of our NoMachine configurations. One suggested a tweak to the NoMachine settings which helped a lot. Another is using Xming instead and says the performance is much better. I just haven't gotten around to trying it. Before this issue with deleting huge blocks of text, the only speed-related problems I've had with Vim in this setup have been its response to termresponse strings and the updating of windows in diff mode. I haven't seen the termresponse issue in a while and the tweak to NoMachine seems to have fixed the diff-mode refresh issue. I hadn't had any problems with the clipboard before this attempt to delete almost 50k lines. I seldom delete that much and usually copy and paste no more than a couple of pages of text. Any other slowness due to my use of the clipboard has been negligible. A workaround of deleting such large amounts of text to the black hole register would be OK as long as I remember to specify that register _before_ starting the deletion. For most of my work, the benefits of setting the clipboard to unnamed outweigh the disadvantages. It allows me to easily copy and paste between multiple Vim instances, some of them running on Linux and some running on Windows, without having to prefix each operation with "* or "+. I also run autocutsel (see http://mutelight.org/articles/subtleties-of-the-x-clipboard) so that anything I copy to the primary selection is automatically copied to the clipboard and vice versa. Regards, Gary -- -- 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.
