tracker issue : CFB-3758872

select a category, or use search below
(searches all categories and all time range)
Title:

Color coding with comments breaks easily

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Raymond Camden / cfjedimaster (Raymond Camden)

Created: 05/12/2014

Components: General - IDE

Versions: 3.0

Failure Type: Cosmetic Issue

Found In Build/Fixed In Build: PublicBeta / 289834

Priority/Frequency: Normal / Most users will encounter

Locale/System: English / Platforms All

Vote Count: 1

I think I may have logged a bug for this before. This is hard to reproduce consistently, but I see this a LOT lately with my editing sessions. It is easy to "break" color coding with CF comments. By break I mean the yellow part ends up bleeding out. Here is screen shot:

https://www.evernote.com/shard/s3/sh/6814f497-670b-4bc4-9b9c-b8f77ee1f54a/6c06af89db5c4d15c04eb8bb13db28d7

See how line 20 is marked as a comment? I'm seeing this quite a bit. In this file, the problem is the previous comment. If I remove it, then line 20 isn't colored wrong. 

If I change that comment to

<!--- foo --->

it fixes itself. If I break that into 3 lines, it works ok too. So it seems to come and go. But as I said, I am seeing this often.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3758872

External Customer Info:
External Company:  
External Customer Name: cfjedimaster
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

Comments:

An example of comment coloring breaking. variables.HTTP.setURL('https://maps.googleapis.com/maps/api/place/details/json'); In this case, the text after // is colored yellow. This code is inside a cfscript block.
Comment by External U.
27060 | May 20, 2014 08:03:25 PM GMT
Another example, this time it breaks towards the end. cfhttpparam(type="header", name="Accept", value="application/json,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5");
Comment by External U.
27061 | May 21, 2014 06:42:16 AM GMT
I had fixed this (or rather a similar bug logged by Ray) before CFB 3 final, but looks like those changes did not get merged. The changelist was #289834.
Comment by Ram K.
27062 | May 21, 2014 09:54:45 PM GMT
<!--[if lt IE 7]> <html class="no-js ie6 ie oldie" lang="en"> <![endif]--> This comment will break the code coloring too. <!--[if IE 7]> <html class="no-js ie7 ie oldie" lang="en"> <![endif]--> <!--[if IE 8]> <html class="no-js ie8 ie oldie" lang="en"> <![endif]--> <!--[if IE 9]> <html class="no-js ie9 ie" lang="en"> <![endif]--> <!--[if gt IE 9]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
Comment by External U.
27063 | June 03, 2014 02:30:39 PM GMT
The bug is fixed and will be available in the next CFB 3 update/hotfix
Comment by Ram K.
27064 | June 03, 2014 09:17:30 PM GMT
Code coloring is really, really bad. HTML comments seem to really interfere with the parser. It's almost unusable.
Vote by extuser
27070 | June 04, 2014 03:00:07 AM GMT
To be clear, this fix is NOT released yet, right?
Comment by External U.
27065 | June 12, 2014 06:35:08 AM GMT
Correct, this fix is not released yet
Comment by Ram K.
27066 | June 12, 2014 08:31:18 AM GMT
this is still not fixed in gold with update
Comment by External U.
27067 | July 10, 2014 08:02:51 AM GMT
I'd argue that bugs for CFB (and maybe CF too) shouldn't be marked fixed until a user can download it. I just checked the "Check for Updates" in CFB and I don't see this available. Or maybe a new status, "Fixed/Released" can be used.
Comment by External U.
27068 | July 10, 2014 08:56:17 AM GMT
I agree Ray, this is extremely confusing -- especially since it was marked fix before the previous "hotfix" to CFB. There is nothing more awesome than paying $300 for having the equivalent of notepad coloring for coding. Please release this fix ASAP.
Comment by External U.
27069 | July 10, 2014 09:04:27 AM GMT