@omz, any idea / explanation form your side?

That is exactly one setup I have @TutorialDoctor :

1. Main WF calls the ( modular ) Sub WF and processes the output with actions. Works fine.

2. Main WF calls the ( modular ) Sub WF and processes the output by calling a Python script — I have moved the previous second Sub WF one level up. Here Editorial crashes at every second Run of the Main WF. After killing Editorial the first run is fine again and ... crashes afterwards. Puzzling.

Maybe Editorial doesn't like to process Python in different WFs during one combined run?

Thanks to both of you @ccc and @TutorialDoctor for your replies.

@ccc : I have set up a simplified version of my modular approach and it works without flaws. There must be something else going on. I will investigate and keep you int the loop.

@TutorialDoctor : I have downloaded your WF — interesting approach! Here comes my way:

-- Main WF : defines some ( action ) variables, calls a first Sub WF, which mainly consists of a Python script for producing an out- / input. A second Sub WF ( again a Python script ) is run to construct the final result.

The reason for my approach: I can use the first Sub WF to build some other main WFs. All future bug fixes and enhancements in the WF module will immediately reflect in any Main WFs using it. Nice! No tedious copying etc.

I am working on a side project that uses a modular workflow ( WF ) approach.

The main WF calls a sub WF, which contains a Python script, and afterwards uses its own Python logic to further enhance the output.

Running the main WF crashes / freezes Editorial every second time. Replacing the Python script in the main WF with Editorials Action logic runs flawlessly as expected. The only downside for this approach is the rather long chain of actions.

It looks like Editorial can handle only one ( or maybe more? ) Python script on the same "execution level" at a time.

Is this issue known ( to anyone ) and does someone have a possible solution for it?

Yeah and pleasure! So you are adding / removing the @done tag, if one is using the checkboxes. Good.

If you look at TaskPaper ( TP ) for Mac, notes are greyed out ( a little bit ) to make the difference, but on the font size side no changes are applied. I would like to suggest to stick as much to the original — at least in the beginning — as possible. It will attract even more people using TPM ( Mac ) and looking for an alternative for TPT ( Touch ).

That already looks awesome Ole!

How are checked tasks being translated in the original file and how are you going to handle notes?

Right, reload works with module objects — successfully imported before — only …

Try reload( helpfunc ) at the end of mainprog.py, it should do the math.

Ole is thinking of supporting MultiMarkdown in the future, see http://omz-forums.appspot.com/editorial/post/6488681971974144.

Explain and Code.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. — Donald E. Knuth

The workflow has been uploaded to the directory : http://editorial-app.appspot.com/workflow/6403405396312064/tV42vb3ZIGE.

It allows to extract source code from the Markdown ( documentation ) file. See https://github.com/StefanoRausch/Literate-Source-Code for more information.

Happy literate source coding!