Motivation
show() binds one handle to one specific window (handle.win, recorded once at creation time). If the same buffer is also open in another window (:split/:vsplit), compute_placement only ever computes visibility/position against the original window — the second window renders the reserved blank virt_lines rows with no image in them, for as long as it stays open. This was originally reported as #17 and closed via docs-only (#22, "note ... as a known v0.x limitation") rather than a fix.
Issue #10 ("Multi-location placement fan-out for a single transmitted image", closed via #51) added the underlying primitive this needs — a distinct p= per placement, so one transmitted image id can carry a second, independent placement without re-transmitting pixel data — but it does not by itself detect a split and create that second placement automatically. M.show() still only ever creates one handle bound to one win per call. Today a caller has to work around this manually: call show() again with the second window's win and the same path (documented in README's Known Issues and doc/blit.txt as of #53).
Proposed Solution
Have show()/the renderer detect when its buffer is opened in an additional window (e.g. via WinNew/BufWinEnter, or by scanning vim.fn.win_findbuf(buf) on relevant autocmds) and automatically create a fanned-out placement (issue #10's primitive) for that window too, without the caller needing to call show() a second time. Needs design for:
- Which single "logical" handle/return value represents an image now potentially placed in several windows — does
M.show() still return one handle, with fan-out siblings tracked internally? Or does it return a group?
- Teardown semantics: does closing one auto-fanned-out window's placement also
clear() the others, or only its own (mirroring today's manual-fan-out clear() behavior — per-handle, not per-id)?
- Whether this should be opt-in (a
show() flag) or the new default behavior, given it changes what happens today (blank space) without any API change.
Alternatives Considered
Additional Context
Related: #17 (original bug report, closed docs-only), #10 (underlying fan-out primitive, implemented), #51 (implementation PR), #53 (documents the current manual workaround).
Checklist
Motivation
show()binds one handle to one specific window (handle.win, recorded once at creation time). If the same buffer is also open in another window (:split/:vsplit),compute_placementonly ever computes visibility/position against the original window — the second window renders the reserved blankvirt_linesrows with no image in them, for as long as it stays open. This was originally reported as #17 and closed via docs-only (#22, "note ... as a known v0.x limitation") rather than a fix.Issue #10 ("Multi-location placement fan-out for a single transmitted image", closed via #51) added the underlying primitive this needs — a distinct
p=per placement, so one transmitted image id can carry a second, independent placement without re-transmitting pixel data — but it does not by itself detect a split and create that second placement automatically.M.show()still only ever creates one handle bound to onewinper call. Today a caller has to work around this manually: callshow()again with the second window'swinand the samepath(documented in README's Known Issues anddoc/blit.txtas of #53).Proposed Solution
Have
show()/the renderer detect when its buffer is opened in an additional window (e.g. viaWinNew/BufWinEnter, or by scanningvim.fn.win_findbuf(buf)on relevant autocmds) and automatically create a fanned-out placement (issue #10's primitive) for that window too, without the caller needing to callshow()a second time. Needs design for:M.show()still return one handle, with fan-out siblings tracked internally? Or does it return a group?clear()the others, or only its own (mirroring today's manual-fan-outclear()behavior — per-handle, not per-id)?show()flag) or the new default behavior, given it changes what happens today (blank space) without any API change.Alternatives Considered
show()call): works today, documented as of docs: document the split-window fan-out workaround for show() #53, zero extra implementation cost. Requires the caller to be aware of and explicitly handle the split case themselves.Additional Context
Related: #17 (original bug report, closed docs-only), #10 (underlying fan-out primitive, implemented), #51 (implementation PR), #53 (documents the current manual workaround).
Checklist