Highlighting in nano broken after v2.45.2

[tycode]

I open Git Bash and run a Git command like git commit --amend or git rebase -i HEAD^ - something that opens nano with a temporary file that ought to have Git-specific highlighting.

Observed behavior in versions marked below as "broken": There is no highlighting. Additionally, on further investigation:

• nano /etc/nanorc also does not do any highlighting, implying it is probably an issue with highlighting overall, not Git-specific
• nano -z, which according to nano -h and the nano News page should list the names of available syntaxes, outputs nothing
• ls /usr/share/nano shows all the files I'd expect to see

This happens both when using Git Bash (via MinTTY) and when using the Windows 11 Terminal Profile (created by selecting the relevant option in the installer).

As the last working version of Git for Windows contains nano 8.0, which does not support nano -z, my thinking here is that when nano added the -z option, they also somehow broke something that the Git for Windows build relies on.

Expected behavior: highlighting works and nano -z lists available syntaxes.

Versions tested

• Git for Windows 2.48.1 - contains nano 8.3 - broken
• Git for Windows 2.47.1.2 - contains nano 8.2 - broken
• Git for Windows 2.46.2 - contains nano 8.2 - broken
• Git for Windows 2.45.2 - contains nano 8.0 - works
• Git for Windows 2.44.1 - works
• Git for Windows 2.43.0 - works
• Git for Windows 2.42.0 - works

Full install information

• Components: Open Git Bash Here, Git LFS, Add Git Bash Profile to Windows Terminal (no others)
• Editor: nano
• Branch name: master
• Git from the command line and also from 3rd-party software
• Bundled OpenSSH
• Native Windows Secure Channel library
• Checkout as-is, commit Unix-style line endings
• Use MinTTY
• Only ever fast-forward
• Credential helper: None
• Extra options: Enable file system caching, disable symbolic links
• Experimental options: disabled

[dscho]

Is this also broken in a regular MSYS2?

[tycode]

@dscho

I think it quite possibly is, since installing the latest version of MSYS2 (which has nano 8.3) and entering nano -z also outputs nothing. However, I imagine due to some difference in environment, nano there has no coloring at all (i.e. the help bar for instance is not colored). An older installation - which happens to have nano 8.0 which is the version used in GfW 2.45.2 which works - has the exact same behavior (no coloring at all). So it seems it's not possible to tell for sure.

Although I do occasionally use regular MSYS2 I've never had a need to use highlighting in nano in it, so I never noticed the lack of coloring there before. I'd love to try to track this down but unfortunately regular MSYS2 doesn't provide a way of switching to specific older versions AFAIK, unlike GfW where the history of self-contained installers makes it easy to test. It looks like it might be possible to try specific older versions of individual packages but this technique doesn't accurately reproduce having an older version of the entire installation.

Have you been able to reproduce the issue on your end?

Screenshots

MSYS2 - no coloring

GfW 2.46.2 - broken: coloring, but no highlighting

GfW 2.45.2 - working: coloring and highlighting

Apologies for the redaction, but you can still see the highlighting on the comments and the first character of the commit hash and message.

I neglected to included it in the screenshot, but $TERM is xterm inside GfW.

[dscho]

Based on a quick look, I think that all you need is to uncomment this line in /etc/nanorc

# include /usr/share/nano/*.nanorc

[tycode]

...indeed, you are correct. Somehow, I did think to check that the default setting of "is highlighting enabled" hadn't changed between versions, but not whether the highlighting files were included by default or not...

Rather than editing /etc/nanorc, I've just put include /usr/share/nano/*.nanorc in my ~/.nanorc (so that it will be kept even after any future updates!!), so that's resolved it for me. I do feel like quite an idiot now - thank you, for taking the time to point out what I should have noticed!

With that aside:

It looks like nano upstream has always had those inclusions disabled in its example config.

Do you know what the origin of this change is?

Both my MSYS2 installations have those inclusions disabled, so my guess now is that some very old version of Git for Windows set up some "helpful" defaults without making sure that they would be retained after an upstream update, and the recent minor upstream change to remove the double-quote characters on those lines overwrote the downstream change without anyone noticing.

Would it be worth either restoring the previous default (if this was indeed an intentional decision by GfW originally) or putting a quick "the default has changed, here's what you need to do to keep old behavior" note in a changelog for anyone else who may get stung by this?

[dscho]

Do you know what the origin of this change is?

Huh. I looked and looked and could not find anything, seeing as MSYS2's package recipe copied doc/sample.nanorc verbatim and doc/sample.nanorc.in has had those include lines commented out in v8.1.

But then I looked at git-extra's post-install script which Git for Windows uses to make quite a few adjustments and saw where it edits /etc/nanorc, and I think I figured it out: It expects the line to end in a double-quote, but as of nano's v8.2~7 commit, the arguments of the commented-out include directives are no longer quoted!

[dscho]

Unfortunately, the fix for this just missed the cut-off for v2.49.0-rc1; I am finishing the touches on the patch and will open a PR Real Soon Now™, though, and it should be in v2.49.0-rc2.

[tycode]

Thanks again for looking at this!