There are even checkboxes on the page to simultaneously disable ligatures and enable texture healing. They're just controlling whether various subfeatures of font-feature-settings are off/on.
I have a bunch of font-feature-settings subfeatures turned off explicitly in my userChrome.css, so it took me a little while to realize that that was what was messing with this site. I couldn't figure out what texture healing was supposed to do because toggling it wasn't helping, but it was because of my userChrome.
First let me say that there is no support like Stripe support. :-) I'm always greatly relieved when onboarding with a customer and they both use Stripe and Stripe subscriptions. But to your point, I may know something about Churn Buster supporting folks not using Stripe subscriptions or even using other payment processors. Email me at andrew@churnbuster.io for more information. :-)
Regardless of the name, this is a Rails engine for Stripe integrations put together by the guy who wrote the book on Stripe integrations for Rails. Definitely worth checking out.
I prefer working on front end stuff, not necessarily because I think working on the back end is worse, but because it's more immediately rewarding.
With frontend work, you get to see the results right away, and interact with the user interface, and I guess that in a way it's closer to visual design part because of controlling interactions and making decisions (in some cases) about the way that users will interact with the app.
Congratulations - This is really a huge step forward for both Ember, and front end development. I know that it has been possible to build rich front-end applications using JavaScript before now, but the API and tools around Ember are excellent and really make for a productive, convention over configuration development environment.
This is great - I've been using Yeoman since the first 1.0rc, and have to say that the tool chain is excellent and covers all the main parts of development with ease. Easy to bootstrap a new project, intelligent defaults for code organization, testing and minification for production.
I haven't found anything else that comes close for solely front end dev work.
I like the features it has, but every time someone post a link to fish shell, I wonder why I would switch from bash or zsh. Will this really be THAT MUCH BETTER? Will I just run into weird errors? Is it totally sh compliant? These are important things to know and should be on the homepage.
I am a year-or-two-old fishshell convert who is reasonably well versed in bash and tried using zsh and bash with a big .bashrc.
A few things stand out to me as huge pluses:
- It has a lot of cool functionality out of the box such as highlighting, smarter autocomplete (type in a partial word at the prompt and hit up instead of the cumbersome bash ctrl r/s history prompt that loves to beep at you), directory history (alt left-arrow and alt right-arrow), and more.
- You don't need a 10k .bashrc or 1k .zshrc to unlock most of that cool functionality, it's just enabled by default. So anywhere you have fishshell installed, you get 95% of what you're used to, no need to git clone or scp over your .bashrc.
- Startup time is _very_ quick compared to bash or zsh with said 10k .bashrc or 1k .zshrc, and is comparable to bash or zdh with no startup file.
The only weird error I ever ran into was with an older version of fish shell complaining about missing directories in your PATH every time there was an automatic completion available. I have not run into that issue with newer releases.
It is not sh-compliant, which will occasionally wreck havoc when you have a program that shells out without explicitly using sh. I remember running into this issue specifically with vim and emacs on more than one occasion, but truth-be-told I consider this a bug with those programs rather than a fault with fish.
There's also the matter of it not being installed on some machines, but I've used bash for so many years now that my brain flips back into bash-mode anytime I see that familiar colorless prompt with a dollar sign at the end.
It's not an essential upgrade. I also wouldn't bother using it for shell scripts either. But I'd say give it a boy scout try for interactive usage and see how you like it.
I fully agree: The sensible and intuitive defaults (ie. arrow up/down for history; tab/rightarrow for autocompletion) and simply so much which just works out of the box (beautiful styled completion list with program descriptions in it, colors, sensible help) made me instantly fall in love with fish.
Be sure to try Fish 2.0 which is even much more awesome than the older version.
My apologies, I was being a little facetious. Just a little. :)
The size difference was based on my intuition that when I maintained my own .bashrc and .zshrc, I was able to "get away" with fewer total lines in my .zshrc than my .bashrc. I remember my .bashrc being dozens of pages, my .zshrc was only a couple.
Compare that to my fish init file...all it does is set a few paths and aliases and turn off the greeting, because everything else just works out of the box for me.
It's also remarkably fast because I took great effort to optimize the parts that happen the most. Shell is actually pretty fast if you don't fork and exec all the time...
Well, it's about 400 lines total. Roughly 40% of that is PATH handling functions: add_to, append_to, replace_in, remove_from, prefix and unprefix. They're used like:
add_to PATH /usr/sbin
prefix and unprefix are a macro for a bunch of standard replace_in/remove_froms:
...All of which are managed by different package managers (stow, brew, ports).
All that stuff is the part I optimized so that it only uses bash built-ins and never execs. Converting that away from sed/perl shaved about 8 seconds off my startup time (it's now so fast I don't notice it).
The next 20% is interactive stuff. Setting up the prompt, aliases, stty, etc. This is generally more complicated than it technically needs to be because it's cross platform so it'll run on any unix-y thing with no changes.
Then remaining 40% is a big chunk of shell functions that are mostly unused in my day-to-day life, but kept there to jog my memory if I need to do a certain task.
That adds up to 100%, but it's also worth noting that 27% of that is blank lines and comments.
I am not sure I would include oh-my-zsh as someone's personal zshrc. Moreover I thought OP had made a distinction between bash (10k) and zsh (1k) so I am not sure how o-m-z counts as a bashrc? I will take your word for it but I cant imagine what people put in there bashrc to get to 10k. The entire bash-it repository is 8,588 and over a third of it is bash completions which seems to duplicate the majority of what is already provided by bash-completion. And I am not sure that bash-completion is really "my .bashrc."
The thing that's stalled me out from using fish before is that it's different enough from the Bourne shell that it seriously interrupts my day to day usage; but it's TOO similar, with the horrible shell semantics. So it's never really been worth it to me.
> If you want coding ligatures but do not want texture healing, you can elide the calt setting: