Fixed in git, commit 7c174a1a, by using the proposed regex.

Putting the coloring rule for single-line comments before the rule for strings has at least two effects: 1) Characters after the closing quote of a string that contains a double slash still get colored as a comment; and 2) quoted things in line comments get colorized bright yellow as if they were super important.  Both these things are not nice.  So I don't want to change the order of the coloring rules.

However, I've done some grepping through several source trees with:

grep -R -e '//.*".*"' -e '".*//.*"' | grep '\.cc\?:'

This shows that a URL in a string is relatively common, so it would be nice not to miscolorize such a string.

So... I would propose a comprise: not always require whitespace before the //, but only when the comment contains a double quote.  In other words, this:

color brightblue "//[^"]*$|(^|[[:blank:]])//.*"

This allows a line comment to follow directly after other characters as long as the comment does not contain a doubele quote -- if it does, then the // needs to be preceded by a blank (or be at the start of the line).

Comments?

(My apologies ... I'm bored and perusing the nano bug tracker, as one does ... Happy New Year Benno!)

Not offering a complete solution here, but, one of the nicer features of nano's syntax highlighting is that the highlighting is "incremental". (or "cascading", I suppose).

In other words, you are not limited to a single regex doing all the work. You are allowed to apply the highlighting in multiple passes, each of which is allowed to override the previous one in some way. I've used this to great effect to create my own syntax highlighting for a terminal ticket tracker I've been working on. The whole nanorc scheme took me about 10 minutes to write because of this. By contrast, getting the vim syntax highlighting to work was a complete nightmare which lasted 2 whole days, because the regexes needed to be exact to cover all the different cases as different conditionals ...

I note that in the c.nanorc file, the regex for strings is above the regex for comments

So, as a partial solution here, perhaps the simplest thing to do is to have the "// comment" coloring regexes higher up in the syntax file instead, and then have the string rule further down the file, which results in "overwriting" things when if it spots a string.

You'd have to split the multiline comment to appear even further down the file though in this case, otherwise you'd get strings within multiline comments highlighted as well.

Not a full solution, since there's a chance you may be left with some trailing blues after the string is closed. But, food for thought :)

Having said that, I don't think this is that huge of an issue. I note that python behaves the same way; e.g. "my phone is #12345" will paint everything after the # in red, even though the whole thing is technically a string.

Tyvm for your response.  I have used about a day and a half to learn Perl regex (perlre).  I can't say I wasted my time, as I was able to come up with a solution that satisfies all cases.  The only caveat is if it immediately follows a colon ':'.

# Comments.
color brightblue "(^|[^:])//."*
color brightblue start="/\*" end="\*/"

Hoping this is good enough to be changed.

The current nano package has a highlight file for c programming files that includes highlights for comments:

# Comments.
color brightblue "//."*
color brightblue start="/\*" end="\*/"

This works for almost everything, except http(s) references in strings.

My work around has been:
# Comments.
#color brightblue "//.*"
color brightblue "^//."*
color brightblue " //."*
color brightblue start="/\*" end="\*/"

Comments cannot immediately follow anything but the start of the line or a space.  Thus, "http://www.here.com" will be highlighted in yellow, as strings should be, instead of the latter half of the address being 'brightblue'.

I'm sure others may find this useful as well.