Another comment system (syntax hilighting) issue

[JSacharuk]

I was going to post this in the other thread, but decided to keep this seperate.

I was looking through a file and most of it appeared to be commented out. I looked on a colleauge's machine, and it wasn't. We went back and looked at it, and here's how it went.

Code: [Select]

void thingie::foo()
{
    <some code>
    //*

    if( stuff )
    {
        //* text
        //* text
        //* text
        <code>
    }
    else
    {
        //* text
        //* text
        //* text
       
        if( morestuff )
        {
            <code>
        }
    }
    /**/
}

Everything after that /**/ at the end appears in red -- my comment colour. It gives the appearance that the whole file is commented out...right up until there's another section that has a /**/.

Removing it fixes the syntax hilighting, and the next /**/ breaks it again.

This isn't my code, and I suspect that someone put that in because the //* earlier was breaking THEIR hilighting. Still, this isn't the right behaviour.

[Dswag89]

I was going to post this in the other thread, but decided to keep this seperate.

I was looking through a file and most of it appeared to be commented out. I looked on a colleauge's machine, and it wasn't. We went back and looked at it, and here's how it went.

Code: [Select]

void thingie::foo()
{
    <some code>
    //*

    <code snipped>
    }
    /**/
}

Everything after that /**/ at the end appears in red -- my comment colour. It gives the appearance that the whole file is commented out...right up until there's another section that has a /**/.

Did you mean that everything after the //* is in your comment color?  Everything from right after <some code> to the /**/ near the end?

Removing it fixes the syntax hilighting, and the next /**/ breaks it again.

This isn't my code, and I suspect that someone put that in because the //* earlier was breaking THEIR hilighting. Still, this isn't the right behaviour.

It appears to me to be some confusion in setup between a C++ style comment "//" and a C-style comment "/*".  If a person had SlickEdit set up to *not* recognize C++ comments, then SlickEdit would see a / followed by /* right after the <some code> line.  This would start a standard C comment.  Then, it would look for the matching */ and comment-color everything in between.  If you're comparing two machines, compare the "comment" setup pages to find the delta.

HTH,

Dan

[JSacharuk]

I was going to post this in the other thread, but decided to keep this seperate.

I was looking through a file and most of it appeared to be commented out. I looked on a colleauge's machine, and it wasn't. We went back and looked at it, and here's how it went.

Code: [Select]

void thingie::foo()
{
    <some code>
    //*

    <code snipped>
    }
    /**/
}

Everything after that /**/ at the end appears in red -- my comment colour. It gives the appearance that the whole file is commented out...right up until there's another section that has a /**/.

Did you mean that everything after the //* is in your comment color?  Everything from right after <some code> to the /**/ near the end?

Nope, I mean it exactly like I said it. It would have made more sense the way that you suggested it.

Removing it fixes the syntax hilighting, and the next /**/ breaks it again.

This isn't my code, and I suspect that someone put that in because the //* earlier was breaking THEIR hilighting. Still, this isn't the right behaviour.

It appears to me to be some confusion in setup between a C++ style comment "//" and a C-style comment "/*".  If a person had SlickEdit set up to *not* recognize C++ comments, then SlickEdit would see a / followed by /* right after the <some code> line.  This would start a standard C comment.  Then, it would look for the matching */ and comment-color everything in between.  If you're comparing two machines, compare the "comment" setup pages to find the delta.

I should point out that I'm basically the only person here that uses SE. I figure it probably did something weird with the visual studio.net parsing. (Vim got it right on my colleague's machine, which is why I noticed this at all.)

[Dswag89]

Oh, now I think I get it, you "snipped" thingie::foo out of a file... you're saying that from the /**/ down through other functions in the file (to the next /**/, you see commented out, right?).  To revise my guess, I'd now guess that maybe the version of SE you're using (BTW, what version is it?) needs a space after the /* to be considered a comment.  Have you checked your comment set up to look for this?  If it is a new version (I'm now using 11.0.1), make sure there's not a "/* " (note the space) in your open comment field.  Also to test this out, put a space in the /**/ that is messing everything up to see if it helps.  If it doesn't try putting a word in there... what happens?

FWIW, I cut-and-pasted your code into 11.0.1 and it does not exhibit the same behavior.

Dan

[JSacharuk]

Hah, you're totally right. This is my fault.

When I was fiddling with trying to get my comments to wrap properly, I added /** as a valid start delimiter for a multi-line comment (since they're everywhere in my code, and I thought maybe it was a problem). The end delimiter is still */, but I'm sure the parser is only seeing that I have a start delimiter followed by a slash.

Good call, thanks.