Re: global command slow when clipboard=unnamed

2014-05-30 Fir de Conversatie Praful Kapadia
Thank you - point taken about quotes being redundant in my set clipboard=.

I completely forgot about the black hole register! Thank you.

On Friday, 30 May 2014 00:48:51 UTC+1, ZyX  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 
 Hash: SHA512
 
 
 
 
 
 
 
 On May 29, 2014 9:25:05 PM GMT+03:00, Praful Kapadia praful...@gmail.com 
 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.
 
 
 
 Do not mislead yourself. '' character starts a comment, so
 
 
 
 set clipboard=
 
 
 
 is equivalent to
 
 
 
 set clipboard=unnamed
 
 
 
 which is really (after you strip comment)
 
 
 
 set clipboard=
 
 
 
 . There is also no need to balance quotes:
 
 
 
 set clipboard=unnamed
 
 
 
 means the same thing. Use
 
 
 
 let clipboard=...
 
 
 
 syntax if you want '' to start a string and not a comment.
 
 
 
 
 
 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/dThe string should match about 150,000
 
 lines i.e. you want to delete lots of rows!
 
 
 
 If you do not need to *cut* lines (any Vim delete operation cuts by default) 
 you need to use black hole register: delete _ in place of just delete 
 (d is the short form of it).
 
 
 
 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!
 
 
 
 Thanks
 
 
 
 Praful
 
 
 
 --
 
 --
 
 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.
 
 -BEGIN PGP SIGNATURE-
 
 Version: APG v1.1.1
 
 
 
 iQI1BAEBCgAfBQJTh8dWGBxaeVggPHp5eC52aW1AZ21haWwuY29tPgAKCRCf3UKj
 
 HhHSvm8TD/90z5dINDuy3tFr7RcSzd671AYa1yeBEEEfY4/dLtWebdl9nNPROFSk
 
 tJ0E9X+fyAb5zbBs+tdhtTj8Zk5wEMtcYqNDJvtkIQKEQy2o+iJKXgKNKqKF11gN
 
 YWQm0jpA5TlW7mLhSXR3AsqYXHHLKiWeRx/s+G2T8GW8GWX5/w3CbwOx88lSo7FQ
 
 K7zs+LoF8UQoXmxZjzT3XKSwve9KRhIQB9VqjvREtmBzOGS8ZW+8GNvApMqAcbdG
 
 y0HZ616R4gW8wl4yuDeWeNfIbAAYyOvzz6+hDrFtwNeNHnPf0os5+bBHNe/be6DP
 
 8oml7sRr80pAsfLjbYx2nsImKNTX/+BBCmd2s+VQzjgJJFZzQ2Z6tcDhb4WKtFCU
 
 0KLbmCHDE0fVkRr14gzPsNSPgA+bHLiYFMxwoZUjs5E2gv96VY1hYTlhDxCq4nx1
 
 s5FWHUIAGwrjUDE5cY68jbxhmm6pNRrMzO0m2kQlwWjy02KgtC2+gNFNxqEq7U1a
 
 LtcVIp7tuOFud0SUvA4yVhcMdsxUdF8LYe9MCzLmrWAjE6vT16OeFJCO+Q44f8LX
 
 rJdtaDOnj5rEK+fEpQDDOQXCkGm4uli0egJ/gcd9EpwlrLoTnPDDGTGRAn3G4Bun
 
 i3sJDX6bVSXSYo+XISaa0n5HvsxltzF4f8QbOVeRhIDHVtAbuJSzEA==
 
 =t81i
 
 -END PGP SIGNATURE-

-- 
-- 
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

Re: global command slow when clipboard=unnamed

2014-05-30 Fir de Conversatie Praful Kapadia
Point taken about quotes being comment indicators in my set clipboard=.

I completely forgot about the black hole register! Isn't vim wonderful just to 
have that concept!

Thank you ZyX - and John for making sure I didn't miss the black hole advice.

Praful

-- 
-- 
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.


Re: global command slow when clipboard=unnamed

2014-05-30 Fir de Conversatie Praful Kapadia
On Friday, 30 May 2014 12:27:01 UTC+1, Christian Brabandt  wrote:
 This is a known issue for windows (see :h todo.txt and search for 
 
 :g/test/d)

Thanks Christian - and apologies to all for not seeing the todo list

 
 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 may try the patch or probably wait until it enters the main code base. 
:g/test/d_ has already entered my muscle memory - probably because the 
alternative is so disruptive!

Praful

-- 
-- 
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.


global command slow when clipboard=unnamed

2014-05-29 Fir de Conversatie Praful Kapadia
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/dThe 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!

Thanks

Praful

-- 
-- 
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.