I think the real problem here is "decision making" as opposed to "collaboration"
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)
We built the Shell Plugin Store into Fig[https://fig.io] to solve a lot of the problems mentioned in this thread. Namely:
* Plugins are hard to install/uninstall
* Plugins are hard to customise once installed
* Plugins add bloat and/or degrade performance in shell load time
* It's hard to find plugins in the first place (there is not centralised directory)
* It's hard to sync plugins and configurations across devices
In Fig, adding a plugin is easy as clicking a button. And if you have issues with it, you can uninstall in a click too
Founder of Fig here. For context, Fig integrates with your existing terminal and shell.
A few things we've found:
1. Developers are understandably opinionated about their terminal/shell setup. It's a matter of personal productivity.
2. We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal.
3. Most terminal "collaboration" happens asynchronously not synchronously (e.g. shared scripts, CLIs, secrets etc as opposed to live terminal sharing)
4. Most of the collaboration happens at the shell level not the terminal level
Given the above, we made the conscious conscious decision not to build our own terminal.
This Google Trend graph shows an increase popularity. The increase has been fairly linear since 2014 but there were notable spikes in late 2021 and early 2022
RegExr is my go to tool for testing regex. It’s always been able to solve my needs and I’ve never had any need to change. In saying that, I’ve always wondered if regexr is missing out on something that other regex build/test tools have?
But also just to clarify, the intention for this post was how to fix this issue if it had already occurred NOT a "how to install brew correctly" guide.
If the issue had occurred, you wouldn't need to run the eval command again, it would have already been run 1,000 times from your .zprofile. Hence I suggest just to delete all references of it then add back one.
But I do take your point that my post could also have been seen as ambiguous and hence added in your suggested changes.
Completely agree. There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system vs just doing it for them and making sure they don't make a mistake.
Perhaps a better implementation would be a choice:
You need too add `eval "$(/bin/brew shellenv)"` to your dotfiles. Would you like us to do this for you?
1. Yes
2. No I will do this myself
I'm pleased that there is more innovation in the terminal emulator space. For a tool used by just about every developer, not a ton has changed since the launch of the VT100 [1] in the 70s.
Fig adds autocomplete [2] to your existing terminal. Soon, we're launching the ability for you to build your own visual apps and shortcuts (like these: https://fig.io/videos/old-sizzle-reel.mp4) and share them with your team or the community.
Rather than building our own terminal, we integrate with the terminals you already use (even the one embedded in your IDE). This means everyone on a team can collaborate but keep using their existing terminal and shell setup.
Yep I mistyped. Meant to say standard "suggestion" format. Trying to imply that each suggestion conforms to a specific standard that we have set but that lets you customise things like the text it suggests, what is inserted, icon etc
> Looks really cool, but I would always use zsh-auto-complete.
Thanks for this feedback. Would love to dig in a little more here. What is it about Fig that turns you off? Is it the idea of having a GUI in the terminal?
> Personally, something like this w.r.t. VC means that incentives will diverge and they lose touch with what it means to be a dev tool.
> Most abstractly I think the misaligned incentives is what happens. I'm not convinced that VCs get dev tools and don't ruin them.
I'd love to hear a little more about your thoughts here. We've committed to making autocomplete free for individuals. In your opinion, what else can dev tool companies like ours do to make you feel more comfortable?
I can't think of a single time where having someone else review my work or give me feedback is a meaningfully bad thing. It's an opportunity to learn. But getting feedback is different to making the final decision.
Instead, the real problem is the either 1) lack of knowing who makes the final decision or 2) requiring everyone must agree to a final decision. You will move a lot faster if you know who the final decision maker is, ideally have fewer (or only one person) making that final decision, and encourage people to make decisions quickly (most decisions are reversible anyway)