diff options
author | zeertzjq <zeertzjq@outlook.com> | 2025-03-03 10:53:03 +0800 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-03-03 10:53:03 +0800 |
commit | 948179cb19c75a9e79cdf2c86c441304c5285e81 (patch) | |
tree | 606d747392d93674adb32a929aecb12c0c1c0f16 /runtime/lua/vim/keymap.lua | |
parent | 560b8a8ce0f89e72b73c2a625f2ff6ad923c8183 (diff) | |
download | rneovim-948179cb19c75a9e79cdf2c86c441304c5285e81.tar.gz rneovim-948179cb19c75a9e79cdf2c86c441304c5285e81.tar.bz2 rneovim-948179cb19c75a9e79cdf2c86c441304c5285e81.zip |
vim-patch:9.1.1165: diff: regression with multi-file diff blocks (#32702)
Problem: Vim's diff block merging algorithm when doing a multi-file diff
is buggy when two different diff hunks overlap a single
existing diff block (after v9.1.0743)
Solution: fix a couple bugs in this logic:
1. Fix regression from v9.1.0743 where it's not correctly expanding the
2nd overlap correctly, where it always expands without taking into
account that this was always taken care of when the first overlap
happened. Instead, we should only grow the 2nd overlap if it overhangs
outside the existing diff block, and if we encounter a new overlapping
diff block (due to overlap chaining).
2. When we expand a diff block to match the hunk size on the orig side
(when handling the first overlap), we expand the same amount of lines
in the new side. This is not sound if there exists a second overlap
hunk that we haven't processed yet, and that hunk has different
number of lines in orig/new. Fix this by doing the corresponding
counter adjustment when handling 2nd/3rd/etc overlap by calculating
the difference in lines between orig and new side.
(Yee Cheng Chin)
closes: vim/vim#16768
https://github.com/vim/vim/commit/bc08ceb75572dcac57ef5019f3d0df6e8290c0f9
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Diffstat (limited to 'runtime/lua/vim/keymap.lua')
0 files changed, 0 insertions, 0 deletions