GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||
GeezerVison is showing github.com — Concurrent workspace builder (opt-in) by tony · Pull Request #1067 · tmux-python/tmuxp Conversation
Member
Summary
Changes
Supersedes #1056, re-homed onto the #1066 builder framework as a separate opt-in builder rather than changing the default. #1056's CLI progress / before_script / synchronize-panes follow-ons are intentionally out of scope here. Test plan
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
|
There was an error while loading. Please reload this page.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@ ## master #1067 +/- ## ========================================== - Coverage 82.55% 82.50% -0.05% ========================================== Files 31 32 +1 Lines 2768 2932 +164 Branches 518 550 +32 ========================================== + Hits 2285 2419 +134 - Misses 346 364 +18 - Partials 137 149 +12 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Sorry, something went wrong.
There was an error while loading. Please reload this page.
why: The per-window pane-construction body was inlined in ClassicWorkspaceBuilder.build(), leaving no override point for a builder that wants a different pane-creation strategy without duplicating the window iteration, plugin hooks, focus handling, and build events. what: - Move the per-window pane loop into an overridable _build_window() that returns the window's focus pane - Have build() call _build_window() and keep on_window_create, config_after_window, after_window_finished, focus, and window_done unchanged around it - Add a doctest for the new seam
why: Loading a workspace waited on each pane's shell prompt one at a time, so a window with several panes paid the prompt-startup cost serially even though tmux warms every pane's shell concurrently. what: - Add ConcurrentWorkspaceBuilder, an opt-in builder that creates a window's panes up front, waits for their prompts in one shared barrier, lays out once, then dispatches each pane's commands - Port _pane_has_drawn_prompt and _wait_for_panes_ready (one shared-timeout polling loop, 10ms interval) from the source change - Port _split_pane_reclaiming_space (reclaim layout space only on a no-space split failure) and the sequential fallback for panes whose start_directory depends on an earlier pane's command - Respect workspace_builder_options.pane_readiness via the classic _pane_readiness_wait resolution; skip the barrier under never - Register the `concurrent` entry point and export the class - Register the module's doctests with the tmux-fixture set in conftest - Add functional tests: multi-window/pane build, command dispatch, single-pass layout, readiness policy, space reclaim, sequential start_directory fallback
why: The new opt-in builder needs user-facing guidance and an API reference page, and the change should be discoverable in the changelog. what: - Add a Concurrent builder section to the custom-workspace-builders guide and list it under Choosing an approach and Reference - Add the concurrent autodoc page and link it from the builder index grid and toctree - Add a What's new CHANGES entry under 1.74.0
5cb2b19 to
01102ad
Compare
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.