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

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

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

Raspunde prin e-mail lui