There is going to be a lot of duplication between nano-syntax-highlighting and nano itself when it comes to its nanorc files, which begs the question if we should be removing the nanorc files from nano entirely since they're almost certainly going to be superceded by nano-syntax-highlighting.

There are a few that nano-syntax-highlighting doesn't cover, and also, scopatz's files haven't seen a release in a while, so some of nano's files are better ATM. Constantly choosing which ones would be better OOTB is a nightmare so we could just go with scopatz as default and let users choose if they want.

In D12018#202171, @abdulocracy wrote:

There are a few that nano-syntax-highlighting doesn't cover, and also, scopatz's files haven't seen a release in a while, so some of nano's files are better ATM. Constantly choosing which ones would be better OOTB is a nightmare so we could just go with scopatz as default and let users choose if they want.

Yea I think I'd prefer that (having nano-syntax-highlighting enabled by default). Saves having both enabled.

On further thought, I'm not sure if including scopatz's as default is a good idea. There hasn't been any activity for nearly a year, and after numerous nano updates, some of the files are buggy (even nanorc.nanorc).
Seems it's best to include the scopatz files with lower precedence, so we have up-to-date definitions from nano and scopatz fills in definitions missing upstream (as hinted to in their readme).

Wonder if it might be worth playing with that --lite flag they have in scopatz. In my mind it makes sense to use the upstream nanorc if available and then supplement with scopatz. The main thing I was hoping to see us fix was vendoring scopatz in our own package sources.

The current state of the patch does just that, complimenting the upstream nanorc files, by including the scopatz files higher up than the upstream files.

Those aren't the same thing. With the current state of this patch both sets of syntax are always fully read in and parsed. The nanorc language doesn't assume that files are separate entities, they are more like scripts which get executed in order of inclusion. If you have two different files containing a syntax with the same name, the one read second takes precedent, but nano will have already read the previous syntax definition into memory. With --lite the files don't get installed at all in scopatz which means that only one syntax is read in instead of two.

Yes they do, with the --lite option all that happens is the script includes the scopatz definitions higher up than the upstream ones. All of the scopatz definitions are still included.

This prevents the duplication, but we do get a very long list of includes. What do y'all think?

I don't feel comfortable with us making these modifications during build time. I would rather this be a separate script that gets run by the packager, echos out the content with a note to "replace all contents in our nanorc after # xyz comment where everything after this is generated" sort of thing. That way the changes can be audited during package updates or be done independently when nano-syntax-highlighting is updated.

Would also be nice to have to either be provided a separate list of where each nanorc is coming from, or for the changes to our files/nanorc be limited in this patch to just those syntax changes, otherwise it is harder to audit all the changes.

Sorry, I gave them more credit than I should have and didn't read through the script to see what it was doing. My point still stands that having both get imported is problematic.

I don't think we should be modifying the nanorc at all during build time. It should be static. And don't think we should be using individual includes for different syntax files either. What I'd like to see is:

1. Our vendored nanorc gets updated
   • To the latest upstream example
   • Without the modifications we had previously
   • With a single line to include the syntax files from nano
   • With a single line to include the scopatz directory
2. Duplicate nanorc files in scopatz be removed entirely from the install when they are present in nano itself
3. A note in this repo to always make sure scopatz is modified when new nanorc files are added or removed from nano

In D12018#202291, @DataDrake wrote:

2. Duplicate nanorc files in scopatz be removed entirely from the install when they are present in nano itself
3. A note in this repo to always make sure scopatz is modified when new nanorc files are added or removed from nano

I thought about the same thing, but that would mean we ship the scopatz package tainted and people who might prefer the definitions there would be unable to switch to them easily.

I guess it is easy enough to fetch from GitHub though, if they really do choose to use them.

@abdulocracy, I've had some time to think it over and I think the integration bits are fine as-is, but this will need a rebase on the newer nano package.