I understand where TFA is coming from here. A lot of these tools are built to handle complex tasks and thus while powerful are complex themselves. It's also tru

I understand where TFA is coming from here. A lot of these tools are built to handle complex tasks and thus while powerful are complex themselves. It's also true that computing has changed a lot, and we've learned a lot since someone defined how `find` would work; maybe we'd do it the same or maybe we wouldn't, but it's definitely true that things are a lot different now. But I think we should be careful before dismissing the existing CLI/TUI landscape. It's a huge achievement that it's possible for code written in over a dozen scripting languages will just run across different architectures and platforms. A #!/bin/sh script running on a Raspberry PI, a WiFi router, a $20k server, a $300 Chromebook, or a $200 Pinephone will run exactly the same. That's because the standards and technologies that script relies on are ubiquitous. They don't cater to the top 1% of computer users, and they don't change every 5 years when average screen resolution increases. Which is to say, be careful what you wish for. It's pretty easy to modify your CLI or your semantics when you're not installed on millions of routers across the world [0]. With success comes backwards compatibility concerns, and it's not too long before people start writing blog posts about how your tool needs to "shed historical baggage". CLI tools are typically respectful of your resources, resources like: - network bandwidth - screen size - attention - CPU/RAM/disk We should keep this in mind when we're talking about what defaults make sense. Does enabling LSPs by default mean you have to download a bunch of LSPs you won't use? Does it mean you've gotta maintain a database of LSPs you use/installed? Does it mean I can't use it on a Pinebook Pro without taking 10% off my battery life? Is this core computing infrastructure like grep, find and xargs or something a little more niche like ripgrep or fzf? Does making this interface colorful respect a user's color configuration on their machine (colorblind users, users avoiding blue light, users who setup a desktop theme, etc.)? If this tool generates an error, will it dump 1 error line in my logs or 13? If it generates 100,000 errors because I was processing 100,000 things, will it dump 100,000 error lines in my logs or 1.3 million? I'm not saying there are clear answers here. My point is that while TFA argues there are clear answers, I'm saying there aren't. You have to target a use case. Andrew Gallant (ripgrep author, among other bonkers things) says he deliberately skipped .gitignore files by default because that's the use case he was targeting. That's great, and I can totally understand where he's coming from. I could also understand a different tool not doing it for different reasons. Neither is correct or incorrect (aside: as engineers, I think we could be taken more seriously if we stopped trying to argue our aesthetic preferences are correct or optimal or whatever--it's OK to just prefer things). Pick a use case. Pick an aesthetic. Pick a mental model. So, yeah write Helix, write new CLI and TUI tools. But don't do it because existing tools are old and busted or fundamentally incorrect (according to you). Do it because you have a different aesthetic preference (you like colors, you like emoji, you like autocomplete, you like WASD as cursor movement). You don't need the backing of righteous engineering gods before you build something you like. Let me have Vim and I'll let you have PyCharm. Let me have Gleam and I'll let you have Go. There's room enough on this disk for both of us. [0]: https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-ftp/ https://daniel.haxx.se/blog/2020/04/15/curl-is-not-removing-...