6 ms·

I'm loving how coreutils is getting improved and with how TUIs are exploding. It's just been a breath of fresh air. I hate to reach for my mouse. Side note: in

I'm loving how coreutils is getting improved and with how TUIs are exploding. It's just been a breath of fresh air. I hate to reach for my mouse. Side note: in vim you can press K to see the help page for a specific function. The default is the man page but some plugins will fix this though I'm not aware of one that's let me get away from documents and help files completely (I'd love to pick up docs of the codebase I'm working on. Anyone know of something that will?) But one thing I want to stress, the defaults of these tools should be the same as the originals as much as possible. This makes them more effective and adoption seamless. To give two examples fd and ripgrep default to respecting your .gitignore file. If you're not expecting this you can easily land yourself in trouble. Sure, it's in the readme but people are installing through their package managers so it doesn't matter. I'm glad the option exists, but don't make it the fucking default! We have aliases for that stuff. It's always better to error in the direction of too much output than too little. Output can be parsed and searched, but you can't when it's not there. Btw, here's what pacman says extra/fd 10.2.0-1 Simple, fast and user - friendly alternative to find extra/ripgrep 14.1.0-1 A search tool that combines the usability of ag with the raw speed of grep So I'm surprised people are surprised that people think you can just alias find or grep, since they are advertised as such and this is also what's said through word of mouth. (Yes, people should open man pages and visit the GitHub, but let's be real about our expectations)

kstrauser 2y ago
I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the many decades since the originals came out, and tailored for the common use cases today. It’s rare that I want to grep, say, the node_modules directory in a JS project. The default of showing the results that git says are my own code is very useful. And as you say, there are aliases if you want to get off the beaten path.
- godelski 2y ago
  Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
  - poincaredisk 2y ago
    >Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
    - godelski 2y ago
      A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
  - setopt 2y ago
    Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?
    - Timwi 2y ago
      Or just have a command-line option to specify an ignore file. That's strictly more useful because then you're not arbitrarily limited to files named “.gitignore”.
      - setopt 2y ago
        rg, fd, etc. all use not only .gitignore, but also merge in rules from a global gitignore in your home directory, as well as a local .ignore file that takes precedence over .gitignore. Setting up all that with CLI flags is a lot of work for what is arguably a sensible default.
        godelski 2y ago
        > Setting up all that with CLI flags is a lot of work for what is arguably a sensible default. alias fd="fd --include-gitignore --include-global-gitignore" alias rg="rg --include-gitignore --include-global-gitignore" I would not consider even a long line like this in your shell's config file "a lot of work". In fact, it seems pretty standard.
burntsushi 2y ago
> 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`.
JNRowe 2y ago
When vim plugins change the effect of K, all they're likely doing is setting keywordprg¹. You can do the same yourself, fex to display info on the commit under cursor you'd use "setl kp=git\ show". You can write little script wrappers to fetch whatever custom resources you want, or you can up your game by writing vim commands so that you can use a count prefix to influence behaviour of the fetch too. ¹ https://vimdoc.sourceforge.net/htmldoc/options.html#'keywordprg' https://vimdoc.sourceforge.net/htmldoc/options.html#'keyword...
- setopt 2y ago
  It’s worth noting that Vim has a lot of these *prg settings you can customize per file type: makeprg, formatprg, equalprg, etc.
- godelski 2y ago
  I've actually found this before but found it hard to parse and little third party information on the subject. I've been able to get K to show things like standard Python docs but not modules and not docs from the active working project. I'm sure there has to be a way considering ctags and jumps exist but I think I need a full weekend you at least unravel all the moving parts without third party explanation.
camgunz 2y ago
This kind of thing isn't without precedent; ls famously ignores files/folders that start with a dot. ripgrep in no way tries to be a drop-in replacement for grep. Not only is it super explicit about it in all the docs, a major raison d'etre for it is its UX, which differs substantially from grep's. Also, it's fine if people make mistakes, flounder, or get stuck. When I installed RedHat 5.0 for the first time it took forever to figure out out how to run programs (gotta use ./), then it took forever to figure out how to use emacs, then it took forever to figure out how to save a file and exit emacs. Along the way I learned a ton about man and info pages, how to page up and page down, the names of the keys... skills and knowledge that have served me literally for decades (OK, maybe not how to use info pages). Not everything needs to be optimized for like, minimal number of clicks to purchase.
- godelski 2y ago
  > ls famously ignores files/folders that start with a dot. This isn't related. There's a specific system standard. It's been that way for decades and is now expected. Last I checked, git isn't part of the unix system, isn't ubiquitous in file systems, and gitignores don't exclusively specify files that are junk or binary (I always exclude build artifacts, like most people, but build artifacts are useful to look at. And I do ML, so I'm never gonna include my checkpoints because git isn't for binaries, but I still want to search for them). > Also, it's fine if people make mistakes, Sure! And we should learn from the mistakes. I'm not arguing fd or rg should change. Momentum is a bitch. But if you're going to build a new tool, don't make this mistake. We've talked about principle of least surprises but let's also talk about the way you have to handle this issue. In my dotfiles, along with thousands of other people, I have alias fd="fd --no-ignore" But now we have an issue. What happens when I want to add back the ignore? Sure, with this example I just do `\fd` but doesn't if I add any of the other likely flags to my alias. So now you have to complexity your argument parser to handle precedence. Which dominates? Ignore or no ignore? Does order matter?[0] You now have to make choices to handle things you wouldn't have had to if you did it from the other way. This design choice requires more complexity overall to meet user demands. Given that aliases are the norm for these kinds of situations, it is not a hard ask to ask users to alias if they want this as the default. But let's talk about that generalization more, because I see this error in software all the time. People think Defaults should be what most people will use This is wrong, for multiple reasons. First, your tools will always take on a life beyond what you expect and you will always be bad at predicting what people need or want (therefore use flexibility). Second, while you should strive for this, there are many conditions that take higher priority. For example the principle of least surprise. Good design should strive for users not requiring a manual. It's almost always impossible to actually achieve, but you still do your best. One key aspect to this is understanding natural feedback. In our example of too much or too little we can see that there's natural feedback so the user can understand. And yes, the feedback will cause the user to likely reach for the manual, but it won't let them think something is right when something is actually wrong! Even if you know 90% of your users would be happy with a specific default this does not override the importance of natural feedback signals. It's why people will still push on a door labeled pull, because the design is telling them the instructions not the label. Labels are just a patch to fix what was just a bad design. Look, lots of design is ambiguous and there's almost never optimal solutions. But our specific example is a software version of a Norman door [0] for our specific example with fd it's probably safe to let the ignore flag strictly dominate but I'm sure you can understand examples where this won't be as obvious and that the conversation at hand actually generalizes far beyond even unix tools and is a general design principle.

kstrauser 2y ago

I strongly disagree. Neither of those tools claim to be drop-in replacements. They’re more like a reinvention of the older tools given what we’ve learned in the many decades since the originals came out, and tailored for the common use cases today. It’s rare that I want to grep, say, the node_modules directory in a JS project. The default of showing the results that git says are my own code is very useful. And as you say, there are aliases if you want to get off the beaten path.

godelski 2y ago
Disagree all you want, you still shouldn't be surprised people aren't expecting this fd: https://github.com/sharkdp/fd/issues?q=gitignore+ https://github.com/sharkdp/fd/issues?q=gitignore+ And I stand by it is strictly better for the __default__ to be unfiltered. This is what people expect in general. > tailored for the common use cases today. *YOUR* common usecases. Grep, sure, it is rare that I want to grep a binary file. But I do want to grep configs and secrets. I do want to find binaries all the time. There are many different ways to program and expecting everyone to program like you or even remotely like you is naive. There's so many things under the sun. Failure analysis is critical when designing anything. So let me rephrase Which do you think is a better mode of failure? 1) Not finding files you are expecting to find 2) Finding more files than you expect to find Or for ripgrep, grepping fewer files than you expect to vs grepping more files than you expect to. It is very hard to argue for one considering we have regex to filter which files we want... not to mention pipes and all sorts of common tools including the tools themselves.
- poincaredisk 2y ago
  >Grep, sure, it is rare that I want to grep a binary file. Case in your point - I grep binary files all the time (mainly to look for strings in complied executables).
  - godelski 2y ago
    A hacker on hacker news‽ But yeah this is why I'm arguing for no filtering by default and why I believe the best designs are the most flexible ones. Because any time I think "nobody would need that" I find a world of people I didn't know about. You can't ever predict the usage, so flexibility and defaults aren't about what fits most people's use cases but what can be easily modified to use cases of any group. I'm definitely too dumb to figure out what everyone actually needs lol
- setopt 2y ago
  Perhaps the best of both worlds would just be to write a warning to stderr by default that files in .gitignore have been ignored (only if such a file is applied)?
  - Timwi 2y ago
    Or just have a command-line option to specify an ignore file. That's strictly more useful because then you're not arbitrarily limited to files named “.gitignore”.
    - setopt 2y ago
      rg, fd, etc. all use not only .gitignore, but also merge in rules from a global gitignore in your home directory, as well as a local .ignore file that takes precedence over .gitignore. Setting up all that with CLI flags is a lot of work for what is arguably a sensible default.
      - godelski 2y ago
        > Setting up all that with CLI flags is a lot of work for what is arguably a sensible default. alias fd="fd --include-gitignore --include-global-gitignore" alias rg="rg --include-gitignore --include-global-gitignore" I would not consider even a long line like this in your shell's config file "a lot of work". In fact, it seems pretty standard.

burntsushi 2y ago

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

JNRowe 2y ago

When vim plugins change the effect of K, all they're likely doing is setting keywordprg¹. You can do the same yourself, fex to display info on the commit under cursor you'd use "setl kp=git\ show". You can write little script wrappers to fetch whatever custom resources you want, or you can up your game by writing vim commands so that you can use a count prefix to influence behaviour of the fetch too. ¹ https://vimdoc.sourceforge.net/htmldoc/options.html#'keywordprg' https://vimdoc.sourceforge.net/htmldoc/options.html#'keyword...

setopt 2y ago
It’s worth noting that Vim has a lot of these *prg settings you can customize per file type: makeprg, formatprg, equalprg, etc.
godelski 2y ago
I've actually found this before but found it hard to parse and little third party information on the subject. I've been able to get K to show things like standard Python docs but not modules and not docs from the active working project. I'm sure there has to be a way considering ctags and jumps exist but I think I need a full weekend you at least unravel all the moving parts without third party explanation.

camgunz 2y ago

This kind of thing isn't without precedent; ls famously ignores files/folders that start with a dot. ripgrep in no way tries to be a drop-in replacement for grep. Not only is it super explicit about it in all the docs, a major raison d'etre for it is its UX, which differs substantially from grep's. Also, it's fine if people make mistakes, flounder, or get stuck. When I installed RedHat 5.0 for the first time it took forever to figure out out how to run programs (gotta use ./), then it took forever to figure out how to use emacs, then it took forever to figure out how to save a file and exit emacs. Along the way I learned a ton about man and info pages, how to page up and page down, the names of the keys... skills and knowledge that have served me literally for decades (OK, maybe not how to use info pages). Not everything needs to be optimized for like, minimal number of clicks to purchase.

godelski 2y ago
> ls famously ignores files/folders that start with a dot. This isn't related. There's a specific system standard. It's been that way for decades and is now expected. Last I checked, git isn't part of the unix system, isn't ubiquitous in file systems, and gitignores don't exclusively specify files that are junk or binary (I always exclude build artifacts, like most people, but build artifacts are useful to look at. And I do ML, so I'm never gonna include my checkpoints because git isn't for binaries, but I still want to search for them). > Also, it's fine if people make mistakes, Sure! And we should learn from the mistakes. I'm not arguing fd or rg should change. Momentum is a bitch. But if you're going to build a new tool, don't make this mistake. We've talked about principle of least surprises but let's also talk about the way you have to handle this issue. In my dotfiles, along with thousands of other people, I have alias fd="fd --no-ignore" But now we have an issue. What happens when I want to add back the ignore? Sure, with this example I just do `\fd` but doesn't if I add any of the other likely flags to my alias. So now you have to complexity your argument parser to handle precedence. Which dominates? Ignore or no ignore? Does order matter?[0] You now have to make choices to handle things you wouldn't have had to if you did it from the other way. This design choice requires more complexity overall to meet user demands. Given that aliases are the norm for these kinds of situations, it is not a hard ask to ask users to alias if they want this as the default. But let's talk about that generalization more, because I see this error in software all the time. People think Defaults should be what most people will use This is wrong, for multiple reasons. First, your tools will always take on a life beyond what you expect and you will always be bad at predicting what people need or want (therefore use flexibility). Second, while you should strive for this, there are many conditions that take higher priority. For example the principle of least surprise. Good design should strive for users not requiring a manual. It's almost always impossible to actually achieve, but you still do your best. One key aspect to this is understanding natural feedback. In our example of too much or too little we can see that there's natural feedback so the user can understand. And yes, the feedback will cause the user to likely reach for the manual, but it won't let them think something is right when something is actually wrong! Even if you know 90% of your users would be happy with a specific default this does not override the importance of natural feedback signals. It's why people will still push on a door labeled pull, because the design is telling them the instructions not the label. Labels are just a patch to fix what was just a bad design. Look, lots of design is ambiguous and there's almost never optimal solutions. But our specific example is a software version of a Norman door [0] for our specific example with fd it's probably safe to let the ignore flag strictly dominate but I'm sure you can understand examples where this won't be as obvious and that the conversation at hand actually generalizes far beyond even unix tools and is a general design principle.