On Sunday, May 8, 2016 at 8:59:24 AM UTC+3, Bram Moolenaar wrote: > Ramel Eshed wrote: > > > 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) > > What system are you using? If on Windows, what compiler? > This plugin is for Linux. I'm using Ubuntu 16.04 (and tested it also on RHEL 5.5).
> > 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). > > You could use the channel log to find out where Vim spends time. You > may need to add more log statements in the code and recompile. > I think that this is a quickfix issue rather than channels. I don't see that problem when running with agrep window or even with quickfix without the qf window opened (there is also the other issue (see #b below) but this one is much more serious). The channels code does exactly the same, no matter which mode we're using to display the results. > > 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? > > Then it would also be slow if you add all the matches at once. Does > that happen? > You're right, I forgot to mention that. It is noticeable also when adding many results at once (you can see this by running :Agrepsetqf after you have a long list of results). > > 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. I'm quite busy the coming days, but perhaps someone else can > have a go at it. > Thanks Bram! > -- > Wi n0t trei a h0liday in Sweden thi yer? > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
