Hello Rudy, thanks for the input.
> I see. Why not match the string exactly once, capturing everything > before, within, and after startAAA and startBBB, and then check if the > captured AAA equals BBB, as mentioned before? I guess we could do that. So we just search for the first @start.* and the first @end.* (not matching the @end type to the @start type during this initial search) and then comparing the type-part after as you suggest. I checked the preprocessor code from plantuml and I guess that makes sense since the preprocessor also works like that (doesn't really allow @end<some_text_not_used_by_any_plantuml_type> ... @end seems to be always "protected" variables which can't/shouldn't be used in any other context). Initially I was thinking that it should be possible to handle this example: @startregex title literalText @endSomeNameNotBeingUsedByPlant @endregex But I rechecked it and the processor of plant doesn't like it. So by simplifying this we would automatically reduce the amount of "matches" in the code. I will propose something beginning of next week and if you see potential to improve just send me the code I should use instead. But wait for the next proposal :-) > I see. That is actually not a bad idea! But, we must call it something > else, like pre-body' and post-body', to avoid confusion. I will rename the parts. > On that topic, we need to refactor for readability, that is simplicity, > starting by the removal of all setq' and repeated when'. The when parts at the moment do different things/different matches... as mentioned before we should have less whens by simplifying the @start @end logic. Concerning the removal of setq: At the moment the first let* initializes the local variables: start end unwrapped-body expanded-body ... then later the setq sets these local variables to a value (or they stay nil). So setq purely acts on these local vars. Then in the end I check if wrapped-body is not nil and return the final body. I will simplify it as you ask for. > [...] Perhaps we could write `inner-body'? Sure. I can change it to inner-body. One other thing (only side-related) I read on the plantuml page this here (this recommendation exists since a few years): https://plantuml.com/preprocessing > Migration notes > The current preprocessor is an update from some legacy preprocessor. > Even if some legacy features are still supported with the actual > preprocessor, you should not use them any more (they might be removed in some > long term future). > > - You should not use !define and !definelong anymore. Use !function, > !procedure or variable definition instead. > > - !define should be replaced by return !function > > [...] This would mean that also the function org-babel-variable-assignments:plantuml (the one that builds currently the !define %s %s parts) could need some refactoring. Instead of !define foo bar we should use the new variable definition: !$foo = "bar". But this would also mean the following breaking change: When using the var inside the body currently users write just foo ... they would now need to change all of the foo to @foo. If you want I could open a new issue for that (to not get off topic in this discussion). How are such things typically handled (recommended migrations to prevent possible future breakage with third party programs)? Best Tim On 3 Oct 2025, at 22:47, Rudolf Adamkovič wrote: > Tim Hansinger [email protected] writes: > >> Here I am searching for the @start<XXX> blocks. >> It will also match e.g. (where _ represents spaces or tabs): >> @start<XXX>__ >> >> It will filter out the start-type (the XXX part) and then use this >> start-type to get the exactly matching end-type (@end<XXX>) ... so >> @end<ZZZ> would e.g. not match. > > I see. Why not match the string exactly once, capturing everything > before, within, and after startAAA and startBBB, and then check if the > captured AAA equals BBB, as mentioned before? > >> We now use the positions of these start/end items to grab whatever is >> BEFORE the @start<XXX> which I called in my code prologue, but it is >> not the prologue that comes from header arguments... it could be >> e.g. when someone writes a comment before @start<XXX>. It will also >> extract the body in between and the epilogue (again this is not the >> epilogue that comes from the header arguments... it is just >> "stuff/text" that someone might have written after the @end<XXX> >> block). >> >> I can through out/remove the pro and epi parts as we probably don't >> need them, I just thought you wanted them in there which seems to have >> been a misunderstanding. > > I see. That is actually not a bad idea! But, we must call it something > else, like pre-body' and post-body', to avoid confusion. > >> Then the extracted body in between the @start<XXX> and @end<XXX> lines >> (or the whole body if no matching @start/@end are found) is sent / >> expanded by org-babel-expand-body:generic as it should. >> >> In the end we then simply put the single elements back together into >> the final complete body... here I am just removing empty list items >> before joining them so no unnecessary newlines are created if e.g. the >> expanded-body is empty. >> >> So my code is not doing anything that is and rightfully should be done >> by org-babel-expand-body:generic. > > My bad, I misread the code. > > On that topic, we need to refactor for readability, that is simplicity, > starting by the removal of all setq' and repeated when'. > >> And you are correct, I should also rename wrapped-body to unwrapped-body. > > That was my mistake, BTW. Perhaps we could write `inner-body'? > > Rudy > > "Great minds discuss ideas; average minds discuss events; small minds > discuss people." --- Anna Eleanor Roosevelt (1884-1962) > > Rudolf Adamkovič [email protected] [he/him] > http://adamkovic.org
