Not all Waiting Snippets Being Run when Opening Bunches from Bunches

[ejf071189]

Consider bunch1.bunch:

TextEdit
    <<#waiting1
    <<#waiting2
___
#[waiting1]
* say "performing waiting 1"
#[waiting2]
* say "performing waiting 2"

I always hear both "performing" phrases regardless of what type of pauses I put in each fragment, which is consistent with the documentation (the snippets both execute simultaneously)

Now consider these two bunches:

---
title: bunch1
---
bunch2.bunch
(pause 5)
TextEdit
    <<#waiting1
___
#[waiting1]
* say "performing waiting 1"

------------------------------------------
---
title: bunch2
---
Mail
    <<#waiting2
___
#[waiting2]
* say "performing waiting 2"

After a long pause, TextEdit runs and I hear "performing waiting 2" and never hear "performing waiting 2", so the waiting task that is in bunch2 is waiting for the apps from bunch1 to launch and the waiting task in bunch1 never gets run. If I change bunch2.bunch to <bunch2.bunch, I hear both phrases again, but "performing waiting 2" is said before the pause.

The desired behavior is for bunch2's waiting snippet to run after its own apps have launched, and then the same for bunch1's waiting snippet. It's even more surprising that bunch1's waiting snippet is somehow getting lost altogether rather than acting similar to how it does when bunch2 is included as a snippet, so I'm guessing something weird must be happening in the queuing logic when nesting bunches. This may be unavoidable based on how waiting snippets are implemented, but including this behavior in the documentation would be helpful to avoid confusion. (Basically, you should really only have a waiting snippet in the root bunch, otherwise you're better off using the pause/delay command.)

[ttscoff]

You found a bug I've been unable to solve. I found this in testing a long time ago and was never able to track down the reason that waiting snippets in nested Bunches were never fired. It's been in the Bugs section of Bunch.taskpaper forever now. I figured I'd wait to see if anyone ever actually ran into it before I pulled any more hair out.

I'll take another look at it with fresh eyes, but simply documenting the bug might be what happens for now.

-Brett

On 22 Mar 2022, at 4:10, ejf071189 wrote:

Consider bunch1.bunch:

TextEdit
    <<#waiting1
    <<#waiting2
___
#[waiting1]
* say "performing waiting 1"
#[waiting2]
* say "performing waiting 2"

I always hear both "performing" phrases regardless of what type of pauses I put in each fragment, which is consistent with the documentation (the snippets both execute simultaneously)

Now consider these two bunches:

---
title: bunch1
---
bunch2.bunch
(pause 5)
TextEdit
    <<#waiting1
___
#[waiting1]
* say "performing waiting 1"

------------------------------------------
---
title: bunch2
---
Mail
    <<#waiting2
___
#[waiting2]
* say "performing waiting 2"

After a long pause, TextEdit runs and I hear "performing waiting 2" and never hear "performing waiting 2", so the waiting task that is in bunch2 is waiting for the apps from bunch1 to launch and the waiting task in bunch1 never gets run. If I change bunch2.bunch to <bunch2.bunch, I hear both phrases again, but "performing waiting 2" is said before the pause.

The desired behavior is for bunch2's waiting snippet to run after its own apps have launched, and then the same for bunch1's waiting snippet. It's even more surprising that bunch1's waiting snippet is somehow getting lost altogether rather than acting similar to how it does when bunch2 is included as a snippet, so I'm guessing something weird must be happening in the queuing logic when nesting bunches. This may be unavoidable based, but including this behavior in the documentation would be helpful to avoid confusion. (Basically, you should really only have a waiting snippet in the root bunch, otherwise you're better off using the pause/delay command.

-- Reply to this email directly or view it on GitHub: https://github.com/ttscoff/bunch/issues/206 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[ejf071189]

Ha! I'm honored to be such an edge case! Serves me right for trying to be so clever in building modular contexts. I was doing some hair pulling of my own just figuring out what was happening so I don't blame you for leaving this one since the pause/delay workaround is adequate (at least in my use case)