:LustyBufferGrep doesn't search in every buffer about lusty HOT 6 OPEN

Thanks for the report. I've been caught by this as well - seems like Vim doesn't initiate BufRead for files given on the command line until they're entered for the first time. Since :LustyBufferGrep searches based on the in-memory buffer (mostly for speed), it won't find any matches in these files.

The workaround I've incorporated into my workflow:

• Don't list multiple files on the command line; do most file opening with LustyExplorer (or through some other Vim-internal means). I use <C-a> a lot within LustyExplorer to open all files in the current view.

Possible solutions:

• When :LustyBufferGrep is called, iterate through all open buffers and BufRead them if needed.
• Quit using the in-memory buffers.

I'd prefer the first solution; the second one probably opens up a can of worms.

from lusty.

Thanks. Actually I don't do that often so it's not that big of a deal but it can come as a surprise for other users. Opening multiple files like that is quite common, I think.

To be honest I didn't notice this "bug" in my normal workflow. I "discovered" it while doing some experiments to answer a question on StackOverflow.

Yes, the 1st solution seems to be the best of the two.

Thanks again for your answer and for this extremelly useful script.

from lusty.

I just found ":bufdo edit" which will load all the buffers into the editor memory.

I am new to vim, so not sure if this helps.

from lusty.

Thanks zoz, in tandem with eventignore, that may just be what we need.

from lusty.

Ok I did some digging and I wanted to share some findings.

• grota/lusty@660f0c463a33e3d6672fd5d52c6905aee4752e89 of mine doesn't actually solves this issue. Sorry about that. I thought I was related to this issue of mine grota/lusty@059be5cea11fa71396c9b2f44dfc9fada2f891df but that wasn't the case.
• The problem here is due to the fact that vim doesn't actually load the buffers 2 and 3 when you launch it like this:
  vim file1.txt file2.txt file3.txt

I also see that we are not the only ones that encounter this "problem", kien's ctrlp solves it like this: https://github.com/kien/ctrlp.vim/blob/master/autoload/ctrlp/line.vim#L36 i.e. by explicitly loading the buffer's content.
I'm trying to do the same in lusty, see the following (proof of concept) patch.
It basically works because I can see that the lines get loaded and grepped but there are still some "structural" issues that I can't quite solve easily: it seems like vim's buffer loading messages break LustyBufferGrep input mode.

I'm basically giving up right now on this issue, but leaving this comment for the posterity.

diff --git c/plugin/lusty-explorer.vim i/plugin/lusty-explorer.vim
index de02b5a..5b4a680 100644
--- c/plugin/lusty-explorer.vim
+++ i/plugin/lusty-explorer.vim
@@ -1474,6 +1474,7 @@ class BufferGrep < Explorer
       # Used to avoid duplicating match strings, which slows down refresh.
       highlight_hash = {}

+      current_bufnr = VIM::Buffer.current.number
       # Search through every line of every open buffer for the
       # given expression.
       @buffer_entries.each do |entry|
@@ -1481,6 +1482,12 @@ class BufferGrep < Explorer
         line_count = vim_buffer.count
         (1..line_count). each do |i|
           line = vim_buffer[i]
+          if line.empty?
+            VIM::command "buffer #{vim_buffer.number}"
+            vim_buffer = entry.vim_buffer
+            line = vim_buffer[i]
+            VIM::command "buffer #{current_bufnr}"
+          end
           match = regex.match(line)
           if match
             matched_str = match.to_s

from lusty.

Late but same problem here.

from lusty.