bugGNU nano - Bugs: bug #64340, the C syntax colorizes a URL in a...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #64340: the C syntax colorizes a URL in a string as a comment

Submitter:  Yonut Smith <yonut>
Submitted:  Fri 23 Jun 2023 02:49:34 PM UTC
   
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 02 May 2024 05:34:03 AM UTC, comment #9: 

The fix was released in nano-8.0.  Thanks again for reporting.

Benno Schulenberg <bens>
Group administrator
Tue 09 Jan 2024 09:27:24 AM UTC, comment #8: 

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

Benno Schulenberg <bens>
Group administrator
Mon 08 Jan 2024 01:04:19 PM UTC, comment #7: 

Seems like a good compromise to me :)

Tasos Papastylianou <tpapastylianou>
Mon 08 Jan 2024 10:35:09 AM UTC, comment #6: 

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?

Benno Schulenberg <bens>
Group administrator
Thu 04 Jan 2024 04:18:17 PM UTC, comment #5: 

Happy New Year, Tasos.  :)

Thanks for your input.  I'll have another look at this over the weekend.

Benno Schulenberg <bens>
Group administrator
Thu 04 Jan 2024 02:31:44 AM UTC, comment #4: 

(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.



Tasos Papastylianou <tpapastylianou>
Wed 28 Jun 2023 06:27:39 AM UTC, comment #3: 

With this regex:

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

the character before the double slash will be colored too.  When it's whitespace, there's no problem, because in this whitespace there's nothing to color (except when switching on visible whitespace).  But when there's text right before the //, then its last character will be colored.  For example, in the line "foobar//comment", "r//comment" will be colorized as a comment.  Not nice.

(When using Perl regexes, it is possible to solve the issue, with lookbehind.  See https://www.regular-expressions.info/lookaround.html.  But nano uses POSIX regexes, which do not know lookbehind nor lookahead.)

Benno Schulenberg <bens>
Group administrator
Tue 27 Jun 2023 07:45:45 PM UTC, comment #2: 

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.

Yonut Smith <yonut>
Sun 25 Jun 2023 06:36:10 AM UTC, comment #1: 

In nano's code, almost all URLs occur inside comments.  Just one occurs inside a string, in winio.c -- I never noticed that it is miscolored.

True, it would be nice if nano didn't miscolor that string.  That can be done by adding '(^|\s)' at the start of the first comment regex, like so:

color brightblue "(^|\s)//.*"

(The '\s' matches not just a space but also a tab.)

But... this would mean that when one adds a trailing '//' comment without intervening whitespace, this comment does not get highlighted as a comment.  I'm not sure what is more important.

Benno Schulenberg <bens>
Group administrator
Fri 23 Jun 2023 02:49:34 PM UTC, original submission:  

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.

Yonut Smith <yonut>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by tpapastylianou (Posted a comment)
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by yonut (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-02 bens Open/ClosedOpen Closed
    2024-01-09 bens StatusNone Fixed
        Assigned toNone bens
    2023-06-25 bens Severity3 - Normal 2 - Minor
        Summary[Wish] Changes to comment entry of c.nanorc the C syntax colorizes a URL in a string as a comment

    Back to the top

    Powered by Savane 3.13-54b4.
    Corresponding source code