I fell victim to this one on authentic “retro” N64 hardware, which has a hard plastic analog stick. Got an enormous blister right on the palm of my hand trying to win this tug of war. Of course, my young brain was able to hyperfocus on the game and completely tuned out any sense of pain in my hand. It was quite gruesome when I finally beat it and realized my hand was torn to shreds. I was at my neighbors place and I remember how shocked their mom was. She applied some cream that I think was meant for severe burns.

Nintendo would later run a campaign where they’d send you fingerless gloves for free to try to do some damage control on all the negative press when reports started popping up.

If you’re just looking to get started with 3d modeling, it’s hard to beat Blender. At the cost of free, it’s by far the most affordable way to dip your toes in some modeling tools.

For many workflows it’s world class. If you plan to do more organic forms or don’t need technical precision, then it’s very competitive or preferable to paid software.

You might find it lacking if you plan to do parametric or technical CAD-style modeling. Even then, I think Blender can be a low cost way to learn what you want in your software before investing in more specialized software. You’ll learn enough of the modeling basics to more fluently navigate what other software provides.

Permissive licenses permit a broader range of use compared to “copyleft” licenses.

“copyleft” here just being a cute way of being the opposite of copyright - instead of disallowing others from what they can do with “copyrighted” code, “copyleft” requires that they (upon request) share modifications to your code.

Permissive takes away this requirement to share your modifications. “copyleft” is considered more free and open source (FOSS), permissive is more business friendly.

Which part sounds off to you? This looks like a very reasonable paper hoping to distill traditional medicine into viable research paths, and does it using a pretty interesting model of compounds and effects.

If all you see is jibber jabber, maybe you should just default to trusting the experts on this one? Like, it’s not in an obscure journal - it’s a highly regarded peer reviewed journal. The authors aren’t random, they’re researchers at some of the best universities in the world (Nanjing University ranks #7 on the Nature Index).

The abstract is about as plain-speaking as it gets in the world of cutting edge research. You can probably look up the handful of domain-specific terminology and have a good grasp at what the research is about.

Maybe those aren’t the same people.

For anyone who’s curious, this is the state of discussing this feature: https://github.com/helix-editor/helix/discussions/8572

I’m not an authority on the helix ethos, but I’ve contributed a bit and hung around long enough to have a good read on their stance on most topics. The project is still young and managing the growing pains of getting a lot of traction relatively early. I think the devs value keeping the maintenance footprint small to keep the project sustainable.

The philosophy of helix’s design is to be a more convenient kakoune, not necessarily a vim. vim is much more widely known, so that analogy springs up more often, but this idea of using piping out to an external command for most operations comes from kakoune.

For features that would introduce significant maintenance overhead, may jeopardize the performance of a more common workflow or where the design goals are still maturing, the team tends to push such suggestions toward being developed as plugins when that system is added. I get the impression that they see the value of this workflow, but would prefer to see it battle tested as a plugin first.

I’ve been there, but over the years I’ve gotten better at avoiding being in this situation.

If you are implementing something for yourself, and merging it back upstream is just a bonus, then by all means jump straight to implementing.

However, it’s emotionally draining to implement something and arrive at something you’re proud of only to have it ignored. So do that legwork upfront. File a feature request, open a discussion, join their dev chat - whatever it is, make sure what you want to do is valued and will be welcomed into the project before you start on it. They might even nudge you in a direction that you hadn’t considered before you started.

Be a responsible dev and communicate before you do the work.