I do not have access to a Windows machine to test. Is someone else able to check that the unit tests now pass in Windows?

@garyttierney, this was exposed on a PR you posted up - if you have time, could you give the unit tests a check?

Hey @ZNielsen, sorry, missed this notification. I'll check it later today.

No worries, open source happens on its own timeline.

Hm, the minimap does seem to work correctly (the highlighted region looks good for beginning, middle, and end of a 100 KiB file) in my editor, but the tests are still failing:

✗ Search - Beginning of file
	Expected "[]" to equal "[[1, 1, 3], [3, 4, 3], [3, 10, 3], [3, 13, 3]]"
		<SNR>48_minimap_test_search_beginning_of_file:5
✗ Search - Beginning of line
	Expected "[]" to equal "[[1, 4, 3], [3, 1, 3], [3, 1, 3]]"
		<SNR>48_minimap_test_search_beginning_of_line:7
✗ Search - End of line
	Expected "[]" to equal "[[1, 4, 3], [3, 7, 3]]"
		<SNR>48_minimap_test_search_end_of_line:5
✗ Search - Multi match per line
	Expected "[]" to equal "[[3, 4, 3], [3, 16, 3], [3, 22, 3]]"
		<SNR>48_minimap_test_search_multi_per_line:5
√ Search - Spanning a line
✗ Search - Many results
	Expected "[]" to equal "[[1, 1, 3], [1, 4, 3], [1, 19, 3], [1, 22, 3], [1, 25, 3], [1, 25, 3], [1, 1, 3], [1, 1, 3], [1, 1, 3], [2, 1, 3], [2, 1, 3], [2, 1, 3], [2, 1, 3], [3, 1, 3], [3, 1, 3], [3, 1, 3], [3, 1, 3], [3, 1, 3], [3, 16, 3]]"
		<SNR>48_minimap_test_search_many_results:8
✗ Search - Long Match
	Expected "[]" to equal "[[1, 7, 21]]"
		<SNR>48_minimap_test_search_long_match:5
✗ Search - History
	Expected "[]" to equal "[[1, 1, 3], [1, 1, 3], [1, 1, 3], [2, 1, 3], [2, 1, 3], [2, 1, 3], [2, 1, 3], [3, 1, 3], [3, 1, 3]]"
		<SNR>48_minimap_test_search_history:11

I tried the changes in Windows (plus the new unit test file) and only one unit test does not pass:

✗ Search - History
	Vim(let):E866: (NFA regexp) Misplaced @
		<SNR>80_minimap_test_search_history:10

It can be fixed by commenting out the changes in the function, minimap#...color_search_get_spans(); specifically from line 795:

let split_char = '\n'
" if has('win32')
"     let split_char = '\r\n'
" endif
let lines = split(git_diff, split_char)

This is the one change with notable problems. For example, it also broke git coloring. This is a screenshot of a dos formatted file to which I made some random changes to and saved. I disabled the line ending changes, and the git coloring works:

If I re-enable those specific changes, the highlighting breaks.

However, I also tried disabling the other line ending changes, and I didn't see any improvement upon making the changes from \n to \r\n. For example, if highlight search didn't work on my Windows machine before, it didn't work post-changes.

Despite writefile() not distinguishing the endings, I found it to work correctly on my Windows machine when creating the test file for t/search_tests.vim. (Well, probably because it's designed to work in C, while Vimscript is just kind of obtuse in comparison.)

Since the problem discussed in the PR was solved by using the Vimscript function writefile(), there shouldn't be a problem with those unit tests anymore. Due to the above reasons, I actually recommend withholding these changes for now.

Apologies for my long absence from this PR. If someone else with a Windows machine has a different experience, please follow up!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.