Hi All, Thanks to Bram and his recent work on channels, I have a preliminary version of an asynchronous grep plugin which lets you work with the available results while grep is still running. I would like to take advantage of this relatively short script to raise some issues and thoughts I have. The plugin can be found at https://github.com/ramele/agrep.
My original idea was to use the quickfix list and add each match to it from the out callback. I had some issues with it, so temporarily (I hope..) I’m using my own window to display the results (“agrep window”). This is the default now and it should demonstrate what this plugin should do eventually. In order to reproduce the quickfix issues, you'll need to tell agrep to use quickfix list instead of agrep window (:let qgrep_use_qf=1). You can install the plugin as is or load it with $vim -u NONE -N -S <path to agrep.vim> 1. Stability: Currently (7.4.1819) when :Agrep returns high number of results (~2800. So we get similar number of callbacks in a time frame of ~2:45 seconds) Vim crashes with: Caught deadly signal SEGV Vim: Finished. Segmentation fault (core dumped) This is more likely to happen when using the quickfix list. But it happens sometimes with agrep window as well. I never see this when I change the out_cb to only process the msg without adding the results to neither agrep window or qf list (-with lines 108-118 commented out). 2. Quickfix issues a. As long as there are not too many matches and the quickfix window is closed you can fire up a search and start jumping to the available matches while the search is still running using the quickfix navigation commands (:cn, for example). The problem is when the quickfix window is opened while the search is active – here there is a serious performance issue, and Vim hangs for a while. You can see this by running :copen and then :Agrep. Choose a search that will generate many results (> 1000). b. As the matches rate becomes higher, Vim will become unresponsive. It may happen for short intervals or it can hangs for a while (for very high rate). By “rate” I simply mean to number_of_matches / sec. To compare, the performance is much better with the agrep window. As I understand (and please correct me if I’m wrong) when using setqflist() to create a new list or add items to the current list, Vim reads all the buffers (as an unlisted buffers) in order to set the hidden marks. I think that this is the reason of the slowness I’m experiencing. If I'm right, maybe the way Vim loads the buffers of the qf list should be changed so buffers will be loaded only when they're been accessed and not when they're added to the list. What do you think? 3. Changing other buffers: As far as I know, there is no nice way to change buffers other than the current one. There is the getbufline() function, but the symmetry is broken since there is no setbufline(). I found a discussion about this from 10 years ago (http://vim.1045645.n5.nabble.com/missing-setbufline-td1155970.html) but I'm not sure if Bram added it to his TODO list or not. In this script I'm using the move_to_buf() and back_from_buf() functions. The problems with this approach are: - It is ugly. - Poor performance (it is slow, you can see the cursor jumping between windows, it can cause Vim to hang). - Difficult to change hidden buffers or buffers in other tab pages. - Is has side effects - It seems to break my undo tree and I'm sure that there are more. I'm not very much experienced with external plugins (like Python) which can change any buffer, but it seems that when using a channel with "out_io": "buffer" the performance is much better. Is it possible to implement such a function based on how it's done there? I think I'll stop here for now. I'm looking forward to get your feedback. Thanks, Ramel -- -- 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.
