3 ms·

> I'm glad the option exists, but don't make it the fucking default! I very intentionally made it the default. It is one of ripgrep's (along with other tools l

> I'm glad the option exists, but don't make it the fucking default! I very intentionally made it the default. It is one of ripgrep's (along with other tools like ack and ag) most important innovations. What you say is absolutely a cost. But it's a cost worth paying because it improves the user experience so much for tons of folks. Other than perf, the defaults are by far the most critical difference between ripgrep and typical POSIX grep programs. So if the defaults were the same as grep, it would be removing the most visible innovation! This default is half the reason of ripgrep's being in the first place. The docs are very clear and upfront about this. It's not reasonable for me to change the tool just because some users won't understand what they're installing. That's absurd. And of course, changing how it works now would be a massive breaking change that would confuse and piss off way more users. So guess what. It is never ever never going to happen.

Y_Y 2y ago
I happily use ripgrep, but naively believed it was just naively looking at whatever files it was pointed at, like grep does. I get it, and it's probably more often than not the desired behavior, but it certainly violated the Principle of Least Surprise for me. Finally, being confused and pissed off is the default state for users. No config will ever be sane enough to avoid rancour.
- burntsushi 2y ago
  When I use `grep` in a code repository and it turns up pointless results in my `.git` directory, that also violates the "Principle of Least Surprise." There's a reason why I don't follow the "Principle of Least Surprise" in any rigorous way, because everyone can be surprised by just about anything. I essentially never use that phrase in my writing or thinking because it's so vague and literally anyone can disagree with it about anything. As I've already acknowledged, the default skipping behavior is a cost. And this is precisely why this behavior is mentioned extremely prominently in all of my materials about ripgrep. The GitHub description: > ripgrep recursively searches directories for a regex pattern while respecting your gitignore The first two sentences of the README: > ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of `rg -h` and `rg --help`: > ripgrep (rg) recursively searches the current directory for lines matching a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of the description in the man page: > ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. Near the top of every release of ripgrep: > In case you haven't heard of it before, ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. Like, I've gone out of my way to make is superbly clear what it's doing by default. I can't control how other people write about ripgrep or talk about it, and just because I can't control that doesn't mean I should just give up that default behavior entirely. I'm not surprised if users miss this. I understand it. This is why I've acknowledged it as a cost. But I think the benefits outweigh the costs. I cannot tell you how many times folks are delightfully surprised (there's that principle again, but in the opposite direction, demonstrating again just how useless of a metric it is) when ripgrep automatically ignores all the junk they don't care about without them needing to think about it at all. ripgrep is an object lesson in the idea that defaults matter. This doesn't mean it's an unmitigated win from every possible perspective. And this is why ripgrep also makes it extremely easy to disable the automatic filtering: `rg -uuu`.
  - godelski 2y ago
    > 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.
godelski 2y ago
> it's a cost worth paying because it improves the user experience so much for tons of folks. You can have the benefit by making it a flag while also maintaining minimal surprise. > if the defaults were the same as grep, it would be removing the most visible innovation! At the cost of increased surprise and decreased utility. I think you're going to disagree with the utility part, but you have all the utility when the defaults are off and you need flags to turn features on. There a reason core utils have the defaults as simple. That's a feature but a bug. > now would be a massive breaking change You're right, it would be a big change. I'm not sure how breaking, but it would be a big change and increase surprise of users which I'm against. I'm not asking that you change it. Damage is done. But I don't think you need to double down on saying this was the right way to do things. You built a tool for things you needed, it got popular, and didn't expect it to get as far of a reach as it did. That's great! But it's also not surprising what are advantages to you are disadvantages to others.
- burntsushi 2y ago
  > You can have the benefit by making it a flag while also maintaining minimal surprise. You're ignoring the benefits of good defaults. So no, I strongly disagree. Your approach does not give the same benefit. > At the cost of increased surprise and decreased utility. I specifically and explicitly acknowledged it as a cost. > But I don't think you need to double down on saying this was the right way to do things. I 100% believe it was the right way to go. As in, it is my opinion that it is a better user experience overall. More explicitly, if I could go back in time, I would make exactly the same design choice even knowing what I know now. > You built a tool for things you needed I didn't build it just for me. ripgrep started out as a tool to benchmark the regex crate. But when I noticed it was as fast as GNU grep in common cases, I decided to turn it into a tool for others to use. At this point, I specifically chose the design I did not just because of its impact on me, but the impact that older tools with a similar design (ack and ag) had on untold legions of programmers. I thought it was the better UX then and I think it is the better UX now. > But it's also not surprising what are advantages to you are disadvantages to others. I don't understand why you're so focused on "surprise." I'm not surprised at all by anything you said. And this insistence on ignoring my acknowledgment of my design having a cost is pretty frustrating.

Y_Y 2y ago

I happily use ripgrep, but naively believed it was just naively looking at whatever files it was pointed at, like grep does. I get it, and it's probably more often than not the desired behavior, but it certainly violated the Principle of Least Surprise for me. Finally, being confused and pissed off is the default state for users. No config will ever be sane enough to avoid rancour.

burntsushi 2y ago
When I use `grep` in a code repository and it turns up pointless results in my `.git` directory, that also violates the "Principle of Least Surprise." There's a reason why I don't follow the "Principle of Least Surprise" in any rigorous way, because everyone can be surprised by just about anything. I essentially never use that phrase in my writing or thinking because it's so vague and literally anyone can disagree with it about anything. As I've already acknowledged, the default skipping behavior is a cost. And this is precisely why this behavior is mentioned extremely prominently in all of my materials about ripgrep. The GitHub description: > ripgrep recursively searches directories for a regex pattern while respecting your gitignore The first two sentences of the README: > ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of `rg -h` and `rg --help`: > ripgrep (rg) recursively searches the current directory for lines matching a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. The first two sentences of the description in the man page: > ripgrep (rg) recursively searches the current directory for a regex pattern. By default, ripgrep will respect your .gitignore and automatically skip hidden files/directories and binary files. Near the top of every release of ripgrep: > In case you haven't heard of it before, ripgrep is a line-oriented search tool that recursively searches the current directory for a regex pattern. By default, ripgrep will respect gitignore rules and automatically skip hidden files/directories and binary files. Like, I've gone out of my way to make is superbly clear what it's doing by default. I can't control how other people write about ripgrep or talk about it, and just because I can't control that doesn't mean I should just give up that default behavior entirely. I'm not surprised if users miss this. I understand it. This is why I've acknowledged it as a cost. But I think the benefits outweigh the costs. I cannot tell you how many times folks are delightfully surprised (there's that principle again, but in the opposite direction, demonstrating again just how useless of a metric it is) when ripgrep automatically ignores all the junk they don't care about without them needing to think about it at all. ripgrep is an object lesson in the idea that defaults matter. This doesn't mean it's an unmitigated win from every possible perspective. And this is why ripgrep also makes it extremely easy to disable the automatic filtering: `rg -uuu`.
- godelski 2y ago
  > 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.

godelski 2y ago

> it's a cost worth paying because it improves the user experience so much for tons of folks. You can have the benefit by making it a flag while also maintaining minimal surprise. > if the defaults were the same as grep, it would be removing the most visible innovation! At the cost of increased surprise and decreased utility. I think you're going to disagree with the utility part, but you have all the utility when the defaults are off and you need flags to turn features on. There a reason core utils have the defaults as simple. That's a feature but a bug. > now would be a massive breaking change You're right, it would be a big change. I'm not sure how breaking, but it would be a big change and increase surprise of users which I'm against. I'm not asking that you change it. Damage is done. But I don't think you need to double down on saying this was the right way to do things. You built a tool for things you needed, it got popular, and didn't expect it to get as far of a reach as it did. That's great! But it's also not surprising what are advantages to you are disadvantages to others.

burntsushi 2y ago
> You can have the benefit by making it a flag while also maintaining minimal surprise. You're ignoring the benefits of good defaults. So no, I strongly disagree. Your approach does not give the same benefit. > At the cost of increased surprise and decreased utility. I specifically and explicitly acknowledged it as a cost. > But I don't think you need to double down on saying this was the right way to do things. I 100% believe it was the right way to go. As in, it is my opinion that it is a better user experience overall. More explicitly, if I could go back in time, I would make exactly the same design choice even knowing what I know now. > You built a tool for things you needed I didn't build it just for me. ripgrep started out as a tool to benchmark the regex crate. But when I noticed it was as fast as GNU grep in common cases, I decided to turn it into a tool for others to use. At this point, I specifically chose the design I did not just because of its impact on me, but the impact that older tools with a similar design (ack and ag) had on untold legions of programmers. I thought it was the better UX then and I think it is the better UX now. > But it's also not surprising what are advantages to you are disadvantages to others. I don't understand why you're so focused on "surprise." I'm not surprised at all by anything you said. And this insistence on ignoring my acknowledgment of my design having a cost is pretty frustrating.