Dragan,

>It does when you close a method, and also in .prg files if you have the Compile On Save set in your editor options. OTOH, the syntax coloring works as you type - you can see a keyword change colors as you type sufficient number of characters. We've just hit its limitation.

Yeah, but it's still not real-time syntaxing. For example if, in VB, you typed: If < condition > and then hit the enter key, it comes back with a message saying: Expected: Then.

>>This behavior isn't exactly new. It's been with us (and been complained about) since syntax coloring first appeared.
>
>The behavior of the semicolon was like this as early as the semicolon first appeared - was it in FP1.0x or before? And yes, we've all been bitten by it sooner or later.

Oh yeah, and I think I mentioned this. The problem is that the syntax coloring is being relied on to differentiate comments from those that aren't.

>>As I mentioned in my other post, there are other instances where syntax coloring doesn't display as it should, yet no one seems to mind those as much as this one.
>
>The reason for this is that it creates a bug which can't be caught without watching line-by-line execution in trace window. Now if effect of a line not being executed is not immediate (for instance you set a property or variable, which doesn't get used in the current piece of code at all), it may be very hard to track down. Basically, it's a waste of time.
>
>My workaround for this is to write longer comments as just free text, mark it all, and then right click, comment. Easy to uncomment later if I did this with code. This little change of habit saved me from this ever since I discovered this rightclick shortcut.

Mine is to write the comments (without semi-colons) first before I write the code. It gives me an outline of what the method needs to do.

>Of course, having the syntax coloring work properly would be nice, but it's nowhere near the top part of my wish list.

Mine neither.