Progress/indicator when grep takes a long time

[hovsater]

I ran grep for a pattern across a large repo, but the buffer appeared empty instantly so I assumed there were no matches. Fifteen seconds later, the actual results finally showed up. It would be great to have a visual indicator that the search is still in progress. Likewise, assigning the results buffer a temporary, descriptive name would make it easier to spot if you switch to other tasks while it’s running.

Thoughts?

[adsr]

Hm, can you share how to reproduce? There should already be a yellow x indicator in the status bar when a command is running:

It sounds like there may be some buffering happening somewhere in your case.

[hovsater]

Hmm, this is odd. I just tried again and now it's working. First I thought it was an issue when running mle inside tmux, but it seems to work correctly both inside and outside tmux. I honestly have no idea why I was seeing this before. 🤷‍♂

On that note, pressing C-x inside the grep buffer while it's still working, hangs the editor though. Can you replicate that?

[hovsater]

@adsr I just managed to reproduce it now. I tried to grep for SectionDetailsIndexAction. See https://asciinema.org/a/7TGghK4H6TyfSpyPZQjrehqAy. This happens both inside and outside tmux.

[hovsater]

Interestingly, if I change my grep pattern to def instead, it starts populating immediately. So it seems to be tied to the pattern for some reason. Switching to another terminal doesn't seem to help. I'm running Ghostty, but I see the same problem in iTerm2.

I wonder if this has to do with grep itself? Perhaps it's not using line buffering in certain cases? Reading the man page for grep, I found the following:

--line-buffered
Force output to be line buffered. By default, output is line buffered when standard output is a terminal and block buffered otherwise.

So I assume what's happening is that for patterns with many matches, the buffer gets full, it outputs what it has processed and continues, whereas for other patterns where there aren't many matches, it waits until either the buffer is full or the command finishes entirely. If that's the case, can you reproduce this behavior?

[adsr]

Hm what source code are you searching in your example? I'm still having trouble reproducing.

[hovsater]

I'm searching our project at work, so I can't really share that code, sorry. But I think what I wrote earlier makes sense. When grep produces few matches it will not fill the buffer in its entirety so the flush wont happen until the command completes, which may take some time if there's a lot of files.

The project in question have a big node_modules folder that isn't excluded by grep. I assume that might be enough to make grep slow enough to reproduce this behaviour.

[hovsater]

@adsr do you still need a reproduce for this? I'm fairly certain the issue is internal buffering done by grep itself. The documentation states you need to use --line-buffered to force grep to use line buffering rather than block buffering.