Hello Rudy, I made a rookie mistake. Sorry for that.
When I wrote: > On Arch I get: > @startuml > :test; > @enduml > > On macOS I get > > @startuml > :test; > @enduml This I incorrect. On Arch I got this result on vanilla Emacs with vanilla org-mode. On macOS I seem to still have used my doom emacs config with enabled :lang module called plantuml (in doom emacs's init.el). This doom emacs module does a regex replace of the plantuml body which results in the backslash I saw. Here's the link to the file: https://github.com/doomemacs/doomemacs/blob/master/modules/lang/plantuml/autoload.el In there this code renames the body: > ;; REVIEW Refactor me > (let* ((body (replace-regexp-in-string > "^[[:blank:]\n]*\(@start\)" > "\\\1" > body)) I am just writing this to tell you that it is not a different behavior in macOS but an doom emacs behavior if plantuml is activated in the init.el. Now to your code suggestion: I need to look deeper into it this week. I haven't had the time yet since I had to analyze the backslash issue first. Just a quick hint: We need to assure it doesn't just work for @startuml but I guess also for all other possible surroundings, so far I found these (that's why just checking for @start... / @end... makes more sense I guess): @startregex / @endregex @startsalt / @endsalt @startgantt / @endgantt @startchronology / @endchronology @startmindmap / @endmindmap @startwbs / @endwbs @startebnf / @endebnf @startjson / @endjson @startyaml / @endyaml @startditaa / @endditaa @startchen / @endchen You wrote: > That will bite us, and in fact, > it already did, as we do not take into account the prologue/epilogue, Could you give me more info / and example on that? What prologue/epilogue do you mean? As far as I understand the plantuml blocks always need to start with @start... and end with @end... everything should be inside these surroundings. That being said: I understand your suggestion and will try to improve my patch / make it more robust. I'm just glad I found the reason for the backslash issue and I guess I will also try to get this fixed in the doom emacs codebase. Best Tim On 23 Sep 2025, at 13:18, Rudolf Adamkovič wrote: > Tim Hansinger [email protected] writes: > >> I do not know yet where exactly this might come from, but I can try to >> find it out. > > Tim, > > I took a closer look at your code, and I think we could do better. > > As it stands, in your patch, org-babel-plantuml-make-body' conceptually > duplicates the work of org-babel-expand-body:generic' when the body is > wrapped in @startuml' and @enduml'. That will bite us, and in fact, > it already did, as we do not take into account the prologue/epilogue, > unlike `org-babel-expand-body:generic'. > > Perhaps a better approach would be to: > > - Extract from BODY the INNER-BODY that is between `@startuml' and > > `@enduml'. > > - Expand the INNER-BODY or BODY, whichever exists, using > > `org-babel-expand-body:generic'. > > - If INNER-BODY existed, add back the the surrounding `@startuml' and > > `@enduml'. > > In code: > > (defun org-babel-plantuml-make-body (body params) > "[...]" > (let* ((default-start "@startuml") > (default-end "@enduml") > (wrapped-body (and (string-match (rx (literal default-start) > (group (zero-or-more anything)) > (literal default-end)) > body) > (match-string 1 body))) > (expanded-body (org-babel-expand-body:generic > (or wrapped-body body) > params > (org-babel-variable-assignments:plantuml params)))) > (if wrapped-body > (string-join (list default-start > expanded-body > default-end) > "\n") > expanded-body))) > > What do you think? > > Perhaps the regular expression for wrapped-body' could be a bit more robust, > to match default-start' and `default-end' at the beginning and > end of the string only, ideally ignoring leading/trailing whitespace. > If you agree, please do improve! > > [Pertinently, the docstring says "If BODY does not contain @startXXX > ... @endXXX clauses, @startuml ... @enduml will be added.". We should > probably be a bit more precise, saying it "If BODY is not wrapped in > ..." or something like that.] > > Interestingly, I also had to change the following function, to keep the > quotes after `!define': > > (defun org-babel-variable-assignments:plantuml (params) > "[...]" > (mapcar > (lambda (pair) > (format "!define %s "%s"" > (car pair) > (cdr pair))) > (org-babel--get-vars params))) > > P.S. `!define' is documented as deprecated and slated for removal, so we > should probably address that too, but we can do that separately. > > Rudy > > "Genius is 1% inspiration and 99% perspiration." > --- Thomas Alva Edison, 1932 > > Rudolf Adamkovič [email protected] [he/him] > http://adamkovic.org
