Ben Schmidt wrote:
-- I would hesitate to implement that more efficient solution due to thisSince all actions to put something on the clipboard but the last one
will be overwritten this could be improved. It's not so easy to make a
generic solution though, instead of "d" for delete it could be any
command. It would involve storing the text to be put on the clipboard
internally and moving it to the clipboard at the end of the ":g"
command.
possible use case: someone uses a clipboard utility that stores their
'recent clipboards' and wants to fill a number of them using a single
Vim command.
For any non-trivial command iterations, it still won't matter. Vim will still
hang and freeze the system because of the overhead of accessing the system
clipboard buffer at every relevant command. The example you gave underlines
this point.
The use case you give will be worse because every yank/delete command will now
incur an extra bit of overhead: in addition to modifying the system clipboard,
your clipboard utility needs to handle the associated clipboard event.
So if I need to batch delete 10,000 lines, vim will modify the clipboard 10,000
times AND the system is going to tell your clipboard utility -- 10,000 times --
that the clipboard has been modified[1]. This is a recipe for crushing your
system.
clipboard=unamed is fine for manual edits and small-range modifications, but it
doesn't scale well when you need to iterate over large buffers. For now, I'm
using the black hole register (eg :delete _ ) whenever I require large command
iterations. (Thanks to Tony Mechelynck for this tip!)
[1] There's also a threshold for the number clipboard events the system will
send to your clipboard utility, which means the "recent clipboards" may not
correctly reflect your vim deletion/yank history; so it still be problematic
under the current design. Again, for manual editing, no problems. But for
scaling-up command iterations, things become more complex.
hang and freeze the system because of the overhead of accessing the system
clipboard buffer at every relevant command. The example you gave underlines
this point.
The use case you give will be worse because every yank/delete command will now
incur an extra bit of overhead: in addition to modifying the system clipboard,
your clipboard utility needs to handle the associated clipboard event.
So if I need to batch delete 10,000 lines, vim will modify the clipboard 10,000
times AND the system is going to tell your clipboard utility -- 10,000 times --
that the clipboard has been modified[1]. This is a recipe for crushing your
system.
clipboard=unamed is fine for manual edits and small-range modifications, but it
doesn't scale well when you need to iterate over large buffers. For now, I'm
using the black hole register (eg :delete _ ) whenever I require large command
iterations. (Thanks to Tony Mechelynck for this tip!)
[1] There's also a threshold for the number clipboard events the system will
send to your clipboard utility, which means the "recent clipboards" may not
correctly reflect your vim deletion/yank history; so it still be problematic
under the current design. Again, for manual editing, no problems. But for
scaling-up command iterations, things become more complex.
You received this message from the "vim_use" 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
No comments:
Post a Comment