Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix long line matches #102

Closed
wants to merge 2 commits into from
Closed

Conversation

Numkil
Copy link

@Numkil Numkil commented May 16, 2015

This pull requests resolve problem #95.

I ask ag to only display the match and nothing else of the string. Then I construct a regex allowing up to 50 characters before and 50 characters behind to be included in the matching result.

Let me know what you think. :)

@Numkil
Copy link
Author

Numkil commented May 17, 2015

I just noticed that -o and --vimgrep do not work together, the -o switch is ignored. I will contact the_silver_searcher about this.

@losingkeys
Copy link
Collaborator

Great idea! Unfortunately I'm having some issues with the branch. When I search my dotfiles for set, it says "no matches", but when I switch back to the master branch, it shows matches (some with annoyingly long lines).

Another thought: will this work for all window sizes? I think it'll still wrap for some windows, which might be ok (because it probably won't wrap that many times), but it'd be nice to get it exact too.

50e30ae is a duplicate from #100 (merged). I can just cherry-pick the other commit when it's ready, or you can rebase the pull, whichever you prefer.

This is another pull that would benefit from tests, gotta be careful when adding regexes to others' search strings 😄.

@iazel
Copy link

iazel commented May 17, 2015

You should notice that grepargs isn't always the regexp, but could include other options, e.g. I usually include a filetypes restriction, so the result would be something like .\{0,50}--ft myregexp.\{0,50}. This also happen if you want to search in a subdir only. I bet @losingkeys has done at least one of these, and that's cause the no-match. Remember also the -Q flag will disable the regexp engine and consider it as simple text, much faster to match, so even if the pattern could be guessed, it's still a bad idea to alter it.

I think the -o flag is enough and to not include it by default, let the user decide when he need it or not (like every other options), plus it's not widely supported (like --vimgrep).

Maybe a good idea to mitigate the problem could be setl nowrap in the quickfix window

@losingkeys
Copy link
Collaborator

Ohh, I didn't think of that. Good catch @lazel. My current g:ag_prg is
ag --vimgrep --smartcase. It should probably handle other ag options too,
like --literal.

On Sun, May 17, 2015 at 6:43 PM, Iazel [email protected] wrote:

You should notice that grepargs isn't always the regexp, but could
include other options, e.g. I usually include a filetypes restriction, so
the result would be something like .{0,50}--ft myregexp.{0,50}. This
also happen if you want to search in a subdir only. I bet @losingkeys
https://github.com/losingkeys has done at least one of these, and
that's cause the no-match.

I think the -o flag is enough and to not include it by default, let the
user decide when he need it or not (like every other options), plus it's
not widely supported (same situation of --vimgrep).


Reply to this email directly or view it on GitHub
#102 (comment).

@Numkil
Copy link
Author

Numkil commented May 18, 2015

Yeah those are some good points, which I didn't think about. And you are right that's I'm sure why it doesn't work for @losingkeys. I had just made this quickly as a proof that it might work, but apparently it doesn't even because -o and --vimgrep don't work together, which is a limitation in ag itself. Maybe just setting nowrap as @iazel suggested is the only way to go even if it's not perfect.

@Numkil Numkil closed this May 21, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants