matijsvzuijlen

Thanks, that makes sense. I actually just parsed aes as related to encryption without even considering how weird that was given the contect.

Yes, I will do that!

Why are all the parameters full words except 'labs'? I find it jarring because to me 'lab' is short for laboratory, not label.

I wrote one for my own use (on Linux): https://github.com/mvz/mdv

What made you decide to squash when merging instead of leaving the commits in the history so you can always bisect?

I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation.

I think it's worse than, e.g., typical yaml files because the nesting is deeper.

If you already know k8s, this is probably true. If you don't it's hard to know what bits you need, and need to learn about, to get something simple set up.

I can understand requiring 100% test coverage, but it seems to me that requiring a test file for every file is preventing your team from doing useful refactoring.

What made your team decide on that rule? Could your team decide to drop it since it hinders improving the design of your code?

What makes you think TDD assumes that? It sounds like the complete opposite of what TDD is about.

For people who, like me, prefer to read the abstract first: https://www.arxiv.org/abs/2508.06471

In such cases, I generally checkout main, do the side quest, and rebase my original branch on top of it. Then, I can just continue without waiting for the side quest to be merged. Depending on the situation, I may make a separate PR for the side quest, but I don't have to wait for it to get merged.

Alternatively, if you don't like rebasing, you can merge the side quest branch into your project branch instead.

Either way, you don't have to wait for the side quest to get merged.

The idea is that --amend would be used before pushing the commit that it amends, and so before a reviewer ever sees the original commit.

Linking to the abstract instead would have been nice.

If you follow SemVer strictly, the version bump is not necessary unless the number of rerenders is part of the documented API.

What could the frameworks do to make it more natural for inexperienced developers to do the right thing?

This means having to keep these branches around cluttering up everything, and makes git bisect a lot more complicated.

The format itself has several warts, like the ancestor list continuation syntax, or whether or not to add a backslash if you want a literal asterisk.

The implementation lacks checking, so for example if you have some text between square brackets, it will often just get dropped even if the contents is not valid as an attribute list.

Asciidoc starts out great but has a lot of surprising gotchas and complexities.

Wasn't that Perforce?

The result looks beautiful but there are too many surprising magical actions for my taste. E.g., I wonder how "Last year MIT handed out 104 degrees to wombats." would be rendered.

Git has a built-in GUI for that. Just run 'git gui'. It's not pretty but it works.

Item (f) in that same Article 6 can be applied to collect data without explicit consent:

(f) processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.