3 ms·

> because everyone can be surprised by just about anything. I don't think you're being honest here and I'm not sure why. Yes, evening can be surprised by anyth

> because everyone can be surprised by just about anything. I don't think you're being honest here and I'm not sure why. 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. > Near the top of every release of ripgrep I addressed this in the OP. People are installing through their package managers and will never see this. I'm glad you do this and it helps because people will go to open an issue and half of them will read the readme, but it's not surprising people don't. Look, I get you're frustrated. Especially since you get people opening issues all the time. I know that this is so frustrating to you __because__ how frequently it comes up. But that doesn't mean you need to backtrack and change things nor does it mean it wasn't the best design. It's okay to have design flaws. The point of my post isn't to argue that rg should change, but that others shouldn't follow this as the default design (again, I like the feature as it simplifies filtering, but defaults with no filtering is best. Especially for filtering tools) > extremely easy to disable the automatic filtering: `rg -uuu`. I'm happy you did this. Thanks. But it is cumbersome to have a default alias like this and then add back gitignore and the global gitignore when you do want it.

burntsushi 2y ago
> 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.

burntsushi 2y ago

> 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.