> I don't think you're being honest here Really? Wow. You are quite quick to leap to accusations of dishonesty! But no, I wasn't being dishonest. I'm serious.

> I don't think you're being honest here Really? Wow. You are quite quick to leap to accusations of dishonesty! But no, I wasn't being dishonest. I'm serious. I do not rigorously use the "Principle of Least Surprise" when thinking about UX. I understand the thinking behind it, and I understand that bad surprises should be avoided and that not all bad surprises are equally bad, but that's exactly the point. It isn't sufficient just to say something is bad according to the Principle of Least Surprise. You had to use additional reasoning to talk about one surprise being worse than the other. > Yes, evening can be surprised by anything, but no, it's pretty clear that it's worse to not get files you're expecting vs get more files than you're expecting. In the later case there's a pretty clear indication you need to filter while in the former there's no signal that anything is wrong. This is objectively a worse case. "objectively" is a terribly misused word and I think you are misusing it here. I don't agree with your conclusion here. In information retrieval, the trade-offs between false negatives and false positives aren't so clear cut. A sea of false positives can be just as devastating as false negatives. The .git directory is perhaps an obvious case to filter out, but there are many that are less obvious but are captured by .ignore or .gitignore. They can waste a ton of time, and it is not so obvious in those cases to say that false negatives are "objectively" worse than false positives. In other contexts, sure, false negatives are worse than false positives. For example, a bug in ripgrep that leads to false positives is probably better than a bug that leads to a false negative. It depends. The key here is to teach users what the expectation is. This is why all of my blurbs introducing ripgrep in any documentation mention the filtering. That some people miss this and get surprised by the results does not mean I have failed. It just means that it is a cost to be weighed against the benefits of filtering by default. I think I've mitigated the surprise factor sufficiently and I think the benefits of filtering by default are immense. They are easy to discount from your perspective because you think it's just as simple as adding a flag. But that presupposes you know about it! This is one of those defaults where I think a lot of folks don't even realize they could benefit from it in the first place. I encourage other tools to follow ripgrep's design and perhaps to even make bolder choices. Because guess what. The existence of new tools does not mean the old tools no longer exist. You can keep doing what you're doing. > I addressed this in the OP. People are installing through their package managers and will never see this. This is why I acknowledged that it's a cost! My goodness. I acknowledged that it's a cost because not everyone will see the blurb. > but it's not surprising people don't. Why do you keep saying this? Do you think I'm surprised that people don't read the docs, even the first few sentences? I ain't no spring chicken. I've been around for a while. And I'm guilty of not reading the docs too. > The point of my post isn't to argue that rg should change, but that others shouldn't follow this as the default design That's not what I took from it. But okay.