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.
After reading this thread, I tried two workarounds, both of which
worked to keep the cursor responsive.
1. "_dgg
2. :set clipboard&
dgg
My 'clipboard' is normally set to
unnamed,autoselect,exclude:cons\|linux
Also, while vim and the xterm are running on Fedora 17, the X server
is NoMachine (NX). The NoMachine client is running on Windows 7, so
anything going to the X clipboard is also deposited in a Windows
clipboard. I don't know what effect that has on the problem, e.g.,
whether the X client must wait for data to be copied to the Windows
clipboard.
For what it's worth, I attached gdb to vim process and found that
while stuck, a backtrace looked like this.
(gdb) bt
#0 0x0000003dbfae8ea4 in poll () from /lib64/libc.so.6
#1 0x0000003dcb22d428 in _XtWaitForSomething () from /lib64/libXt.so.6
#2 0x0000003dcb22e987 in XtAppNextEvent () from /lib64/libXt.so.6
#3 0x0000000000544a52 in xterm_update () at os_unix.c:7068
#4 0x00000000005426be in RealWaitForChar (fd=0, msec=-1,
check_for_gpm=0x7fff63686104) at os_unix.c:5438
#5 0x00000000005423e9 in WaitForChar (msec=-1) at os_unix.c:5139
#6 0x000000000053e273 in mch_inchar (buf=0x89bca8 "", maxlen=64, wtime=-1,
tb_change_cnt=251) at os_unix.c:450
#7 0x00000000005cf494 in ui_inchar (buf=0x89bca8 "", maxlen=64, wtime=-1,
tb_change_cnt=251) at ui.c:199
#8 0x00000000004c682f in inchar (buf=0x89bca8 "", maxlen=192,
wait_time=-1, tb_change_cnt=251) at getchar.c:3082
#9 0x00000000004c6473 in vgetorpeek (advance=1) at getchar.c:2857
#10 0x00000000004c47bd in vgetc () at getchar.c:1627
#11 0x00000000004c4cf1 in safe_vgetc () at getchar.c:1832
#12 0x0000000000512a82 in normal_cmd (oap=0x7fff636864e0, toplevel=1) at
normal.c:638
#13 0x0000000000612681 in main_loop (cmdwin=0, noexmode=0) at main.c:1325
#14 0x00000000006120d0 in main (argc=6, argv=0x7fff636867f8) at main.c:1025
> 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.
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
