Repository navigation
Conversation
A bar that leaves a MultiBar takes its generated label widgets with it, so adding it again labels it once. The stop_capturing() that brings the count to zero flushes the original stream once, as in 4.6.0. A WrappingIO.flush() replacement that raises no longer costs the captured text.
This branch has not been deployed
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
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.
Three behaviours that 4.7.0 changed against 4.6.0 without a changelog line. Each one was found by running the public API of both releases side by side:
MultiBar: pop or clear a bar, then add it againtarget.flush()calls for onestart_capturing+stop_capturingWrappingIO.flush()override raises once: captured textWhat changed
MultiBar labels leave with the bar.
_label_barrecords the label objects it inserts, and_forget_bar(pop, del, clear, a replacement,remove_finished) removes exactly those objects frombar.widgets, matched by identity, so a label of the bar's own that renders the same text stays. A bar that is removed while its labels are being formatted ends up unlabelled. 4.6.0 only avoided the double label onpopby accident:popdid not forget the bar at all,deldid and labelled twice too.One flush when capturing stops.
stop_capturing()no longer drains and delivers itself whenupdate_capturingis the default hook: the hook drains and delivers throughflush(), as it did in 4.6.0. A replaced hook, which may not callsuper(), still gets the stop's own delivery first, so the error chaining and the hook order pinned by the existing tests are unchanged. Flag propagation is split out of_apply_capturinginto_propagate_capturing, with the private signatures left as they were.A failing
flush()costs no text.WrappingIO._delivercalls the publicflush()after the buffer was drained. When that call raises, the taken text now goes back in front of anything written since, and the next flush delivers it in order. A failedtarget.write()still drops its text, so a retry cannot write it twice.Verification
Every number below comes from this tree.
The iterator paths are untouched by this change and the two rounds disagree on the direction there, so that spread is run-to-run noise.
The compatibility script of the release skill could not run (its scripts directory is gone from
~/.claude/skills), so the compatibility result above rests on the 4.6.0 test files, 4.7.0's own test suite and the probes.Where this comes from
A Codex session (29 Oct to 3 Nov) left an 8700-line uncommitted rewrite of the stream wrapper and MultiBar in the main checkout, pinned to these three regressions among 395 failing asserts, most of them bound to private names and hostile subclasses. That rewrite made
start_capturingplusstop_capturing27 times slower andMultiBar.rendertwice as slow, so it was declined as a whole. The three regressions it was right about are fixed here in 60 lines.