Ambiguous documentation for --files-without-matches

[Frost]

The documentation for --file-without-matches states:

-L --files-without-matches
        Only print the names of files that don't contain matches.

When I read this I interpreted it as if I could use it to list files where not of the lines in the parsed files matched my query.

However, the options parsing seems to suggest that something else happens. The code for this option in the switch statement (https://github.com/ggreer/the_silver_searcher/blob/master/src/options.c#L421) sets the invert_match option and does a fall through into the specification for the --files-with-matches option.

The output of this is unfortunately not the filenames of the files that don't contain matches, but the filenames of all files that contain at least one line that does not match the query.

Here's a gist with reproduction steps: https://gist.github.com/Frost/88f3c8d9c704d9b1520b667a2c16da4a

[mdentremont]

@Frost I think this might be a defect vs incorrect documentation.

I would expect -L --files-without-matches to function similarly to grep, who's -L behavior matches the silver searcher docs for -L

[Frost]

@mdentremont That is also my opinion. I wasn't entirely sure on what was the purpose of the feature though, so I only reported that the documentation did not describe the actual behaviour.

[sephraim]

This is still an issue as of version 2.2.0. In addition to @Frost's observations, it appears that sometimes it performs a correct invert match and sometimes it doesn't, depending on where the pattern is located in a file. Take, for example, these 5 text files in the same directory:

test1.txt

foo

test2.txt

foo
bar
bar

test3.txt

bar
foo
bar

test4.txt

bar
bar
foo

test5.txt

foo
bar
foo

Running this:

ag -L 'foo'

Will return:

test2.txt
test4.txt
test5.txt

It works like grep's -L for test1.txt and test3.txt, but not for test2.txt, test4.txt, and test5.txt. So I think this confirms @mdentremont's suspicion that this is a bug.

---

Was just about to post the above when I found some good news -- the PR from @kpengboy was finally merged into master. Rebuilding ag using the latest master branch worked for me. 🙌

[WhyNotHugo]

I'm seeing an issue which I think is basically the same this as described here:

> cat clippy.toml 
# Copyright 2023 Hugo Osvaldo Barrera
#
# SPDX-License-Identifier: EUPL-1.2

doc-valid-idents = ["WebDav", "CalDav", "CardDav", ".."]
> ag -L Copyright | grep clippy.toml
clippy.toml

> ag -l Copyright | grep clippy.toml 
clippy.toml

It seems that clippy.toml is reported as both containing and not containing Copyright at the same time.