Hi Rudy, thank you. Everything's clear now. I'm travelling this weekend but will have time to implement this next week.
Best Tim On 25 Sep 2025, at 12:20, Rudolf Adamkovič wrote: > Tim Hansinger [email protected] writes: > >> [...] it is not a different behavior in macOS but an doom emacs >> behavior if plantuml is activated in the init.el. > > The Backlash Mystery has been solved! :) > > Great work, along with in-depth, zero-magic investigation, Tim! > >> checking for @start... / @end... makes more sense I guess > > Oh, yes! You are right. > > Instead of only capturing the inner body, we need to capture also what > follows after "@start" and "@end". Something along the lines of: > > (rx > ;; TODO Beginning of string. > ;; TODO Match whitespace, if present. > ;; TODO Match "@start". > ;; TODO Match and capture the kind, e.g. "regex", "salt", etc. > (literal default-start) > > ;; DONE Okay "as is", I think > (group (zero-or-more anything)) > > ;; TODO Match "@end". > ;; TODO Match and capture the kind, e.g. "regex", "salt", etc. > ;; TODO Match whitespace, if present. > ;; TODO Match the end of string. > (literal default-end)) > > ;; TODO Check in Lisp we have the same string after "@start" and "@end" > ;; [Regular languages cannot do that.] > >> Could you give me more info / and example on that? What >> prologue/epilogue do you mean? > > Sorry for not being clearer. > > In the current Org code, org-babel-plantuml-make-body' calls > org-babel-expand-body:generic' which is implemented as: > > (let ((pro (cdr (assq :prologue params))) > (epi (cdr (assq :epilogue params)))) > (mapconcat #'identity > (append (when pro (list pro)) > var-lines > (list body) > (when epi (list epi))) > "\n")) > > Notice how it adds prologue/epilogue. > > In your code, if I remember correctly, `org-babel-expand-body:generic' > was not always called, and your code did not touch prologue/epilogue. > Thus, in some cases prologue/epilogue would have been ignored. > > More generally, we want to avoid diverging code paths. The code I wrote > is a possible starting point. In it, we extract the inner body, then > call all the other functions "as usual", and finally add back what the > initial inner body extraction removed. The key idea is to have a single > code path, instead of "if the body is wrapped, then do X ourselves, else > use the standard function for doing X". > > Is this any clearer than my old explanation? :) > > Rudy > > "The introduction of suitable abstractions is our only mental aid to > organize and master complexity." --- Edsger Wybe Dijkstra, 1930-2002 > > Rudolf Adamkovič [email protected] [he/him] > http://adamkovic.org
