Skip to content

Refactor to avoid future Vim merge conflicts - #1706

Merged
ychin merged 1 commit into
macvim-dev:masterfrom
ychin:refactor-reduce-vim-merge-conflicts
Oct 21, 2026
Merged

ychin merged 1 commit into
macvim-dev:masterfrom
ychin:refactor-reduce-vim-merge-conflicts

Conversation

@ychin

@ychin ychin commented Oct 20, 2026 •

Copy link
Copy Markdown
Member

Change how different parts of the MacVim-specific code are added on top of Vim in order to reduce repetitive merge conflicts when sycing from upstream. This should hopefully help reduce churn.

The main strategy is to move declarations to the top rather than at the end, which is frequently touched by Vim upstream. We also want to avoid having to manually re-calculate index numbers which is error-prone.

For keymap.h, we now allocates a fixed offset (210) to the MacVim-specific keys like trackpad gesture swipes. Previously we always re-calculated the numeric values of these keys every time upstream added more keys, but it made the value of "\<SwipeLeft>" inconsistent which is not supposed to be how key values work. Now, we should have a stable value for them that would persist. The value is large enough that there should be very little chance for upstream Vim to add enough keys to cause a conflict.

Change how different parts of the MacVim-specific code are added on top
of Vim in order to reduce repetitive merge conflicts when sycing from
upstream. This should hopefully help reduce churn.

The main strategy is to move declarations to the top rather than at the
end, which is frequently touched by Vim upstream. We also want to avoid
having to manually re-calculate index numbers which is error-prone.

For keymap.h, we now allocates a fixed offset (210) to the
MacVim-specific keys like trackpad gesture swipes. Previously we always
re-calculated the numeric values of these keys every time upstream added
more keys, but it made the value of "\<SwipeLeft>" inconsistent which
is not supposed to be how key values work. Now, we should have a stable
value for them that would persist. The value is large enough that there
should be very little chance for upstream Vim to add enough keys to
cause a conflict.
@ychin ychin added this to the Release 184 milestone Oct 20, 2026
@ychin ychin added the Non User Facing Non-user facing change. These issues do no need to show up in release notes. label Oct 20, 2026
@ychin
ychin enabled auto-merge October 20, 2026 23:46
@ychin
ychin merged commit 17872fe into macvim-dev:master Oct 21, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Non User Facing Non-user facing change. These issues do no need to show up in release notes. platform-mac

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant