I have joint problems in my thumbs and have trouble with thumb-heavy layouts, but have found the Sofle V2 to work well for me. For my hands it is important that the center thumb key be directly below the N and B keys, which the Sofle provides.
I love reST and I think it lost primarily because of distribution. I.e., the people using it did not have large audiences and didn't put much effort into promoting it.
It's a shame because reST is almost as easy on the eyes as Markdown and is much more capable without being too much more complex.
> Zig doesn't even pretend to do memory safety - if you don't free something manually it won't get freed
Preventing memory leaks isn't normally what people mean by "memory safety".
As an aside: a common memory management approach used in Zig is to have a dedicated memory pool for an operation and simply free all of the memory after the operation is over instead of freeing individual allocations.
I don't think the character is that uncommon in the output of slightly-sophisticated writers and is not hard to generate (e.g., on macOS pressing option-shift-minus generates an em-dash).
I appreciate the consideration. I'll be watching Vedro with interest.
I do like the nicer vedro.asserts mechanism. If that works with unittest and pytest it would be really nice. You might get a few converts that way, too.
Your first and second points makes sense. They don't matter much to me, but I see how others could value those things.
Aside: I also don't like the hamcrest syntax. I also don't love unittest's syntax but it's OK and it's pervasive (i.e., available in the stdlib).
The third point is where I start to disagree more strongly.
> I like that there's nothing new to learn, the expressions work exactly like they do in any Python code, with no special test behavior or surprises.
This doesn't seem true to me.
> the expressions work exactly like they do in any Python code
Not to my mind. In normal Python, an assertion communicates something that is unequivocally believed to be true, not something that may or may not be true (a test). Let me see if I can explain it this way, I often use asserts in tests to show (and enforce) something that I believe to be true and must be true, before the test can have any meaning. E.g.,
The "assert" communicates that this is a precondition, the "self.AssertTrue" communicates that this is a test.
I can 100% see that others might not see/care about the distinction, but I think it is important.
> no special test behavior
Well, that's not quite true. You have to handle the AssertionError specially and do some fairly magical work to figure out the details of the expression that failed. The unittest-style assertions just report the values passed into them.
I don't really like that magic, both from an aesthetic standpoint and from a least-complexity-in-my-tooling standpoint. Again, I can understand others making different tradeoffs.