Ihor Radchenko <yanta...@posteo.net> writes: > Another meetup is on July 26. https://emacs-berlin.org/ > Or we can arrange a jitsi call.
Sure, I can be there tomorrow! > To name them, you can use separate ert-deftest statements. Oh sure, but I don't want to clutter the library. > Also, see the attached modified version of your diff - I made it so > that `should' failures immediately provide some clue about expected > result value, that can help to identify which of the should clauses > fails. Ah nice, much appreciated thank you. I was hesitant to split out the main testing function (previously called by `funcall') into its own function out of the same fears as above, but I see now it's not the only one. > The tests are indeed not passing on vanilla Org. I assume that you > tested them with your other patch applied. I tested them on upstream/main... or so I thought, though I now realise that I needed to delete the =~/.emacs.d/straight/build/org= directory to trigger a rebuild of org-mode for the current branch I was on. (Live and learn...) Problem: My testing patch is indeed not working on vanilla Org, but it contains tests that will (presumably) work with the new merge-params patch. Question: What is the order of submission of patches? Do I submit a testing patch first which works strictly with vanilla Org first, and then a new merge-params function, and then yet another testing patch that is compliant with the new merge-params function? Or do I submit the new merge-params function, and then my testing patch on top? Best, Mehmet