The table is misleading isn't it?
It seems to imply that rg can't work recursively,
but [1] states "..ripgrep defaults to recursive directory search...".
I understand that the table might mean that rg doesn't have a flag
to enable recursive search, but surely we care about features
more than flags...
The table doesn't yet distinguish between lacking a command line flag due to absence of a feature vs due to the feature being the default. This is similar to the situation with case-sensitive search in GNU grep, which ends up with a blank cell even though it is the default. See: https://github.com/beyondgrep/website/issues/72
It's a fair criticism but I don't think it is designed to be misleading.
Maybe not designed to be misleading, but misleading nonetheless. For `grep`, `grep -i needle` is (approximately) equal to `ack/ag needle`, but looking at the table I wouldn't think grep supports case sensitivity.
It's going to be two pages ultimately. If you're comparing features, you don't care about the how.
Right now we're keeping all the data in a JSON file that we massage into a chart. Massaging it into a true feature comparison chart, along with a rosetta stone, should be a simple matter of programming. Same thing with the GNU/POSIX/BSD rosetta stone we're working on.
I agree, but I know in my own project that my "competition" is moving, and I don't follow them. Thus any time like the linked one that I create quickly become out of date as they add new features.
[1] https://github.com/BurntSushi/ripgrep#why-should-i-use-ripgr...