I will need some more time to think about your style of coding because it is different from mine — not in a bad way, so this is not a criticism, but it's a bit more involved to think about this. A few things I already saw you may want to tackle in the meantime is:

1. I feel your unit tests are extremely repetitive. When you test for various inputs for a single function, for example, it is much simpler and easier to create an array of test cases at the top of the file, and implement the tester function once. This way the file is more organized, and it will be simple to just add additional test cases in the future.
2. I greatly appreciate your efforts to kickstart testing the codemirror related functionality. The main reason why we don't yet have such tests is literally just because I was too lazy to write those helper functions until now. What I would love to see is to have that a bit more generalized so that we can test more than just the transformation commands in the future. Please do not take this to completely over-engineer that; just start naming things "codemirror-test-utils" or something like that simply so that we know where to add additional functionality as the need arises and we start testing more things.
3. Please don't write longer strings by concatenating them, this looks horribly ugly 🙈 The 80 character column limit is not enforced in cases where the description just takes longer, that is fine. If you really do need multi-line strings (but not in the tests please), you can use backtick-strings.
4. I'll have to think if it's really adequate to have the transform commands implemented using a factory style, because it does add some complexity that is more difficult to disentangle in the future. My first intention was to literally just write command functions as-is (in the sense that they could be copied and pasted into different code bases and they work there, too). I do see the appeal of saving on some code, however, but I'm wondering what your thoughts are on my approach to the table editor commands (see PR feat: Rewrite TableEditor from Scratch #5243, specifically this folder: https://github.com/Zettlr/Zettlr/tree/table-editor/source/common/modules/markdown-editor/table-editor/commands)

I'll be back with a more thorough code review — also please feel free to remove the explanatory comments, because it makes focusing on the code more difficult than necessary. I appreciate the thoroughness, but it is easier to parse if you could transfer that information into your PR description and leave the files!

Thank you already for your help and work!

I feel your unit tests are extremely repetitive. When you test for various inputs for a single function, for example, it is much simpler and easier to create an array of test cases at the top of the file, and implement the tester function once. This way the file is more organized, and it will be simple to just add additional test cases in the future.

I have changed the test fixtures to conform to your preference.

• 9899d09

What I would love to see is to have that a bit more generalized so that we can test more than just the transformation commands in the future.

I have moved the supporting code into a folder per your suggestion.

• 9128bda

Please don't write longer strings by concatenating them.

Updated to conform to your preference in 9899d09

remove the explanatory comments

I have deleted all of them.

I'm wondering what your thoughts are on my approach to the table editor commands

Approach looks solid ✌️ In your case there are distinct differences between chunks of commands... while there is some repetition, it reads well enough.

I only refactored to the composition approach after writing the third text transform command because by then I noticed that I was repeating the same code in every command: in the specific case of these text transforms there's no difference to the CodeMirror algorithm piece... the composition allows the code that's distinct and relevant to just that transform to "pop."

It's easy enough for me to un-compose it.

Sooooooo, after way too long I've been able to give it a Quick Look. And it has proven once more that sometimes letting something sit can change one's perspective on it. I am now much more comfortable reading your code and seeing the benefits of your approach. While I do believe that a bit of the code might be too verbose, that honestly boils down to personal preference, so I don't want you to change anything. I just gave it a skim and will want to try it out myself but I really believe that the code looks good to merge!

So thanks for holding tight during the past four months -- once I'm back at my desktop, I'll give it a quick run and then we can merge it.

I currently think that we can pull this through in two PRs: one that implements the base functionality plus examples (I.e., this PR as it is), and then a second one that simply implements all other transforms you have been discussing!

If you want to, you can already open that second PR (you can close the individual ones), because I'm pretty sure you won't have to change anything! And then we're good to go!

Thank you again for all of this exemplary work!