Tim Hansinger <[email protected]> writes:

>> Hello Rudy,
>>
>> here's the new patch. I tried to add all your suggestions and
>> advanced handling of prologue/epilogue to it.

Howdy, howdy Tim!

I am a bit confused, TBH.

Prologue/epilogue, handled by the `org-babel-expand-body:generic'
function, are *header arguments*, right?  They are not parts of the
body, nor something to be matched with regexps.

Let us consider again, the starting point, now with inline TODOs:

(defun org-babel-plantuml-make-body (body params)
  "[...]"
  (let* ((default-start "@startuml") ;; TODO generalize to @startXXX
         (default-end "@enduml")     ;; TODO generalize to @endXXX
         (wrapped-body               ;; TODO rename to `unwrapped-body` :)
          (and (string-match (rx (literal default-start)
                                 ;; TODO Anchor and ignore whitespace.
                                 (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)))

Is this not *all* we need, if TODOs were fixed?

If it is, then we should not overcomplicate the code with the many
`when' and `setq' and all that.  We need is (1) one `string-match' to
unwrap the body if needed (2) one call to babel to expand the body, and
(3) one `string-join' to re-wrap the body if needed.

Note again how, compared to your original patch, this code *always* runs
the body through `org-babel-expand-body:generic' that handles prologue
and epilogue and who-knows-what in the future.  We want to do that for
robustness.

Rudy
-- 
"'Obvious' is all too often a synonym for 'wrong'."
--- Jeff Erickson, Algorithms, 2019

Rudolf Adamkovič <[email protected]> [he/him]
http://adamkovic.org

Reply via email to