only sort of.
this is the original document defining markdown, and you’ll notice it doesn’t really specify a lot of the things that have compatibility issues across different markdown processors, along with allowing arbitrary html which really depends on where you’re showing it. There’s a list of ambiguous syntax here.
CommonMark is as close to a standard as we have.
tailscale also just has a button to buy/enable mullvad as an exit node. if you’re just looking for a commercial vpn for privacy it works well.
it felt to me like coffeescript solved problems that people had, then js got equivalent features. arguably that could happen to ts as well
I’ve been using vscode in firefox via tunnel to my main machine on my android tablet and it’s been working well enough
fwiw I’ve personally had cashiers refuse to accept them since they didn’t think they were real. not sure how common that is tho, especially now
haven’t looked into protonvpn much, but it’s more or less a different company providing the same service. I imagine the differences aren’t too significant if you trust both companies
they in theory see everything someone does, but in the case of mullvad they have no idea who you are
extensions tend to be the slow part in my experience. after a couple heavy extensions on an already struggling work laptop I’ll frequently outpace it’s input handling and have to wait for it to catch up
I’ve also had none of these issues on jellyfin either
I’ve found it to be less strict than I’d prefer. Things like whether parameters are aligned or indented, whether or not the first one is on its own line, what statements are indented in fluent calls that have blocks, etc.
A lot of other formatters (prettier, anything for python, etc) force something consistent in those cases, whereas it seems like the dotnet formatter prefers to leave things as they were.
I’d love for it to be more opinionated and heavy handed if anyone has suggestions
I refuse to believe that people use a php style guide. I have yet to open a php file in the course of any job that doesn’t mix tabs and spaces arbitrarily on top of numerous other horrors.
Luckily it’s not often that I have to, so sample size may play in a bit…
There is some surprising behavior with some of the features of yaml, mostly arising from the fact that it looks nice to read. Here’s a list of things that you can avoid to avoid a lot of the pitfalls: https://hitchdev.com/strictyaml/why/ . I haven’t actually used strictyaml, but the arguments it presents are pretty solid and some are things I’ve run into in real environments
for people ootl on D like me, this seems to explain the problems: https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_01_01.html