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.
> We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal.
This. I barely use terminal outside of Jetbrains, and heard similar things from other devs.
And people who live in vim/emacs (I used to live in vim)- I would be surprised if they'd pickup something that might interfere with their setup, like tmux or special plugins etc. (forcing login stuff aside- assuming that'll be removed at some point)
But maybe warp folks will find a way to play nice with everything, or be simply too useful to not use.
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
Agreed. Nix always means Nix Package Manager unless NixOS is specified. Its hard to distinguish `Nix` from `Nix package manager` in google trends though, so the "NixOS" trendline might be the best proxy for popularity of the entire ecosystem.
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?
I typically use Regex101. It's been good enough for my needs and I'm just used to it at this point. Looking at RegExr, it seems like the only big difference is that Regex101 supports substitution, though I think I've only used it once.
Ah, I see it now. Usually when I do replace/substitution it's in a larger project so it's not a feature I typically use on the site. Most of my Regex101 use is just figuring out why a regex I wrote isn't executing like I expected.
I normally use the replace/substitution in situations such as:
I have list of, say, 1000+ things/rows in a single column. I want to put them in a single line and separate by comma. It is is pretty easy to go there and substitute \n for ", ".
That said, that's also doable in a text editor, but I like that I can visualize the pattern and results more easily.
- code generator, with support for a lot of languages,
- a complete quick reference with examples,
- an extensive regex library,
- a regex quiz for "golfing" and learning purposes,
Perhaps, most importantly, it runs entirely client side and does not submit any information to the server unless you hit save (which returns a delete link to remove all data). You can even run the website and (most) of its features offline.
Regexr submits all input to the server for processing.
I use regex101.com, that looks a lot like RegExr. I remember using RegExr at some point, and I think I default to regex101 just because the name is a bit easier to remember. I'll try to remember to switch to RegExr since it's open source.
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
> There is a tradeoff between letting user do everything themselves such that they know exactly what's happening in their system
That makes the (IMO false) assumption that people doing things for themselves by following instructions tend to learn what those things do, rather than simply remembering a "magic" ritual that made something work. Some people will take the time to study and learn how the various commands work and the syntax of different shell & scripting languages. Most won't.
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