summaryrefslogtreecommitdiffstats
path: root/runtime/plugin
diff options
context:
space:
mode:
authorSean Dewar <6256228+seandewar@users.noreply.github.com>2024-03-13 20:17:24 +0100
committerChristian Brabandt <cb@256bit.org>2024-03-13 20:17:24 +0100
commit5866bc3a0f54115d5982fdc09bdbe4c45069265a (patch)
tree16adcfa76b9bef4aaab8df06f39e420dd3e02f83 /runtime/plugin
parent21b0a3df8c4abb884489dfcc0c92b1bbe058f291 (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 'runtime/plugin')
0 files changed, 0 insertions, 0 deletions