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.
>
> 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.
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?
Best,
Christian
--
Je mehr Licht man in die Kirchengeschichte bringt, desto dunkler
wird's.
-- Heinrich Wiesner
--
--
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.
