{{ message }}
Repository navigation
Commit 9d4e4f3
committed
workspace(refactor[builder]) route set-option loops through _bulk_set_options
why: Workspace loading dispatches one tmux ``set-option`` per
loop iteration across four hot loops (session ``options``,
``global_options``, per-window ``options``, ``options_after``).
The helper that ``f4c95faa`` introduced provides a single,
batch-shaped entry point for these calls; this commit moves the
existing call sites onto it. Today the helper is a plain loop
so this is a pure refactor (same N round-trips, same observable
behaviour). Once libtmux exposes a pipelined ``Server.batch()``
the helper body can swap internally and the call sites
automatically benefit without further changes here.
what:
- Replace the session ``options`` loop in ``build`` with
``_bulk_set_options(..., scope_flag="-s")`` targeting
``session.session_id``.
- Replace the ``global_options`` loop in ``build`` with
``_bulk_set_options(..., target=None, scope_flag="-g")``.
- Replace the per-window ``options`` loop in
``iter_create_windows`` with ``_bulk_set_options(...,
scope_flag="-w")`` targeting ``window.window_id``.
- Replace the ``options_after`` loop in
``_apply_options_after`` (or equivalent post-build hook) with
``_bulk_set_options(..., scope_flag="-w")`` targeting
``window.window_id``.
Salvaged from libtmux-protocol@2390ce3b. The original commit
described the change as a perf win; against current libtmux
0.56.0 the helper body issues N round-trips per call site (no
``Server.batch()`` yet), so this commit is documented as a
refactor and the perf framing is deferred to whenever libtmux
ships a batching API.1 parent 6ccb059 commit 9d4e4f3
1 file changed
Lines changed: 20 additions & 8 deletions
0 commit comments