feat: read a project on demand when a drawn bead is blocked by its bead - #187
Merged
Merged
Conversation
A collection that draws a blocker held by a project the directory's scope left out now reads that project and draws the blocker as the bead it is, and goes on reading it in every collection after.
The loop holds each configured project it is not reading armed and ready, and moves one into what it polls and accepts on the inbound channel once a collection comes back having read it.
The bd shim answers per tracker, keyed by the directory -C names, so one run can read two projects holding different beads. The docs say a project stating a blocker's prefix is read on demand where the directory chose the scope, and left unread under --project.
A bead named on the command line starts the forest focused on it, and the project read on demand for that bead's blocker draws its own trees behind the same line as everything else focus sets aside. The test compares the named launch with an unnamed one after Shift+F on the bead.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A bead named on the command line reads only its own project, so a blocker held by another configured project was drawn as not read. Where that project's config states the blocker's prefix, bdi now reads it in the same collection and draws the blocker as the bead it is, with its title and status. From then on the project is read and polled like any other, and the inbound channel accepts reports for it. The project's own trees are folded behind the focus on the named bead, like every other tree.
Only a scope the directory chose widens this way, as it already does for a root named on the command line. Under
--projectthe blocker is still reported asheld-by-unreadand nothing is read. A project that states no prefix, or a blocker whose prefix no configured project states, is reported as before, and a project nothing drawn needs is never read.The collector keeps the set of projects it has read on demand, so a reloaded config does not drop them. The loop keeps every configured project it is not reading armed, and moves one into what it polls once a collection comes back having read it.
The bd test shim now answers per tracker, keyed by the directory
-Cnames, so one run can read two projects holding different beads.