🐛 Incorrect use of bright-black background with native less pager on Windows

[ralish]

This is a weird one but after trying to figure it out for the last few hours I'm giving up for now and reporting what I've found so far.

When running delta against two input files the output will have the wrong foreground colour for certain lines, but only on Windows when using a "native" copy of less (i.e. no dependency on any Unix compatibility layer). The less binary you get from scoop meets this criteria, but the less binary included with Git for Windows does not as it depends on MSYS2 and ncurses.

This means that you can't typically reproduce the problem using git diff as that will use the less binary included with Git for Windows unless you've messed about with the PATH environment variable first. The easiest way to reproduce it is to directly call delta from a PowerShell or Command Prompt terminal. Git Bash or Git CMD won't work for the same reason as git diff won't out-of-the-box.

One other requirement: the issue only appears if line numbers or side-by-side view is enabled (or both). I've attached some screenshots to better illustrate the issue. Note that I've changed the "bright black" colour from the default grey to a bright red to make it clearer.

Broken behaviour

Correct behaviour

Additional notes

1. The issue only seems to occur for new lines. It does not appear to occur for the right-side when side-by-side view is enabled.
2. The same delta binary is being used in all cases. I've tested with the latest stable release (v0.16.5) and built from latest source.
3. Although the less binary differs they're both version 643. They use different regex engines, but that feels unlikely to be relevant.
4. The issue occurs in a standard Console Host in addition to Windows Terminal (as in the earlier screenshots).

Final thoughts
I suspect this is probably not a bug in less but I'm not suggesting it's definitely a delta bug either. I wonder if there's some edge case which the MSYS2 or ncurses libraries handle correctly or work around but the "native" Windows terminal does not? Even if so, fixing it in delta may be easier at least in the short term if that actually is the case.