diff options
author | Sean Dewar <6256228+seandewar@users.noreply.github.com> | 2024-03-13 20:17:24 +0100 |
---|---|---|
committer | Christian Brabandt <cb@256bit.org> | 2024-03-13 20:17:24 +0100 |
commit | 5866bc3a0f54115d5982fdc09bdbe4c45069265a (patch) | |
tree | 16adcfa76b9bef4aaab8df06f39e420dd3e02f83 /src/drawline.c | |
parent | 21b0a3df8c4abb884489dfcc0c92b1bbe058f291 (diff) |
patch 9.1.0175: wrong window positions with 'winfix{width,height}'v9.1.0175
Problem: winframe functions incorrectly recompute window positions if
the altframe wasn't adjacent to the closed frame, which is
possible if adjacent windows had 'winfix{width,height}' set.
Solution: recompute for windows within the parent of the altframe and
closed frame. Skip this (as before) if the altframe was
top/left, but only if adjacent to the closed frame, as
positions won't change in that case. Also correct the return
value documentation for win_screenpos. (Sean Dewar)
The issue revealed itself after removing the win_comp_pos call below
winframe_restore in win_splitmove. Similarly, wrong positions could result from
windows closed in other tabpages, as win_free_mem uses winframe_remove (at least
until it is entered later, where enter_tabpage calls win_comp_pos).
NOTE: As win_comp_pos handles only curtab, it's possible via other means for
positions in non-current tabpages to be wrong (e.g: after changing 'laststatus',
'showtabline', etc.). Given enter_tabpage recomputes it, maybe it's intentional
as an optimization? Should probably be documented in win_screenpos then, but I
won't address that here.
closes: #14191
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Diffstat (limited to 'src/drawline.c')
0 files changed, 0 insertions, 0 deletions