WooHoo! My Code Coloring Finally Works!

Posted March 28, 2007 at 9:40 AM by Ben Nadel

Tags: ColdFusion

Reader Comments

I'm noticing something odd in the text output. Instead of your simple cfml comment, I get:

<--- --------------------------------------------------------------------------------------- ----

See all the extra dashes? I get the same at the end of the header as well. I do not see these extra dashes in the normal code view.

FYI, I might "innovate" this into BlogCFC.

Oh, and nice sample code as well. ;)

Good code for an example. Thank you.

I think that is part of his header. I only get that in the .txt file that is produced when clicking the download code and it's only around the header which has the blog entry info. All of the other comments are ok.

Wasn't Ray using something similar on his blog at one point? I know you like reinventing the wheel but have you checked this out: http://www.dreamprojections.com/SyntaxHighlighter/

Boyan, the code coloring on my blog, while nice, is very old. It was made by Doug Cain I believe, many years ago.

I DID try the code you mentioned, dp.SyntaxHighlighter, but it was buggy with CF. RIAForge still uses I think and I need to rip it out soon.

@Ray,

Yeah, I put CFML comments in the TXT download. It just contains a link back to the blog so that if someone ever downloads the code and then has no idea where it came from... it's all right there in the header.

If you are only getting the comment though, something is wrong.

Oh, and feel free to innovate anything you want. My code is your code. I have the code both for the color coding AND the TXT file download posted somewhere on the site. If you want to look at it, just search, or shoot me a comment.

@Kain,

Thanks dude :)

@Ben - no, I'm not getting just the comments. Please reread my comment. When I view your code on the blog, I see simple comments like so:

<!--
..
-->

But the text download is different. it is more like this:

<!-- (lots and lots of dashes)
..
(lots and lots of dashes) -->

So the main concern is - what I see in the browser is not what I see in the download.

@Ray,

I added the header comments for some extra information about the code and where it came from. Do you think it's more confusing that it's worth? When I code, I generally have comments at the top of my files, so for me, it's a matter of habit. But if people are not used to that, I can see that it might be confusing - hey, what the heck is this? This is not what I clicked on?

So I'm confused. Are you saying then that the download should NOT be the same as what a person sees on screen? I'm not complaining about your comments on top. It kind of sounds like you are explaining why you have comments and that is _not_ my problem. Again - my problem is that the code view seems to be different from the download view.

@Ray,

I too am confused :) I think it stems from the fact that these features have been built over time and there are things to consider (and I am sure there are inconsistencies). So here's a basic run down.

In my Database, I have two field for the blog entry:

- content
- formatted_content

The content holds the plain HTML and code snippets (one TEXT field). Yesterday, I added the formatted_content field. This field has the same content as "content" but it has color coded code snippets. I do this so that I do not have to do the color coding on the fly and do I don't have a lot of extra noise in the "content" that is used for other things.

When I enter the blog entry in my admin, it stores it in "content" and then color codes it and stores that value in formatted_content. This lets me do the heavy lifting of color coding on input, not output.

Ok, so then there are ways to access the code. In the standard view page (this one), I check to see if there is formatted_content. If there is a grab that one, else I grab the content. So this page might be pulling from one or the other.

Then, there is the "view code" pop-up that has the cut-n-paste functionality:

http://www.bennadel.com/index.cfm?dax=blog:602.viewcode&start=1094

This page ONLY uses the "content" field. The color coding in the page IS done on the fly and is, in fact, my very first color coding exploration from months ago.

Then, there is the "download code" prompt. This also uses the "content" field, NOT the formatted_content. After all, no color coding needed here. This process is explained here:

http://www.bennadel.com/index.cfm?dax=blog:520.view

That process adds a CFML comment to the top of the file (with the title of the blog and link to the code download) just to give a bit more information for when the code is viewed later on (on your machine).

Now, both the "code view" and the "download code" features strip out all the the UL/LI from the code snippets on the fly, so there might be some room for error there ;)

But, theoretically, the code in the content and the formatted_content fields are exactly the same (when there is data in the formatted_content field). But yes, some of the outputs change depending on the "feature" you are using.

Does that help clear up some of the madness :)

Here is how I do my "view code" pop-up:

http://www.bennadel.com/index.cfm?dax=blog:320.view

I'm very disappointed. I never release software that has bugs or missing features in it. I spend hours with my QA team going over every single facet of the application and ensure it is perfect. I simply do not understand why you cannot do the same. Shame. Shame on you Ben Nadel. May the mouths of a thousand toads bite the hidden parts of your body!

So - um - seriously - sounds like you get me then. So just fix it then. ;) It is a minor nit - but seeing something different, even as simple as extra dashes, really threw me for a loop.

@Ray,

Trust me, that is excellent feedback. Like I said, I am used to having comments at the top of all my files, so it never phased me or even crossed my mind that it would phase others. But if you are not used to it, and that is what pops up on the text file - Above the Fold for that matter - it can certainly be disorienting.

On this note, I will probably remove the comment at the top. It really serves no higher purpose other than to point back to this blog.

I guess that was the week my User Experience Testing room with recording web cam and double-sided mirror was fully booked by someone else ;)

Woah. Dude. Ok, seriously, I don't we are on the same track here. You said,

"Trust me, that is excellent feedback. Like I said, I am used to having comments at the top of all my files, so it never phased me or even crossed my mind that it would phase others. But if you are not used to it, and that is what pops up on the text file - Above the Fold for that matter - it can certainly be disorienting."

Let me be absolutely clear. There is NOTHING wrong with your comments on top. I do the same thing. My ONLY complaint is that what I see in the browser is NOT the same as what I see in the download.

Is that not making sense? It's like I saw:

Hi

in the browser, and

Bye

when i downloaded. THAT is what I'm talking about. The _fact_ that you used comments on top is fine, and again, is what I do as well.

@Ray,

I am not talking about changing the way I code. I was only talking about removing the content form the download-code feature. The comments in my standard files will remain the same.

Maybe I misunderstanding what you mean. If you were me, how would improve the "work flow"?

Heh, we should get on the phone. ;) So you don't understand what I mean? I'll try again. What I see in the browser is NOT what I see in the download.

That's it. Does that not make sense?

Did my HTML example in the last comment make sense?

@Ray,

Is the only difference the CFML comment at the top? If so, would you suggest I remove that from the download?

As far as I know, yes. But why would you remove it? Isn't it a bug that what you see is not what you get?

@Ray, not to beat a dead horse... but would you like me to change my download code thing? Or were you just confused that it was different (and now that you know, it's not an issue)?

I don't think we are still on the same page though. I didn't see a response as to why download != web page. Or did you answer that and I missed it?

I just put the comment at the top of the download file to tie it back into the website. It's like a mini-readMe built into the download. It was just an arbitrary decision.

Ah. Well. Don't do that. ;) It confuses me and makes me angry. Jedi Smash!

"I DID try the code you mentioned, dp.SyntaxHighlighter, but it was buggy with CF." --Raymond Camden

Since dp.SyntaxHighlighter does not come packaged with a CFML "brush," I'm not sure what implementation you're referring to, but the library has good enough groundwork laid in the core file that it should be quite possible to make it work nicely with CFML.

I used either the XML or HTTP brush - I forget which. I spoke with the author of the project, and he did help me a bit. I found a bug where words were duplicated, and I reported it, but I did not hear back. Now I don't blame him for that - I know how hard it is to support OS projects, but the bug was enough for me to remove it from my site, since it made my code blocks harder to read.

I found some bugs in it too... for example, the XML brush (probably among the others) doesn't really support multi-line comments, even though the documentation specifically claims it does (and gives a very simple example that works).

That was very easy to fix (it's a simple matter of replacing "this.GetMatches(new RegExp('<!--\\s*.*\\s*?-->', 'gm'), 'comments');" with "this.GetMatches(new RegExp('<!--[\\S\\s]*?-->', 'g'), 'comments');"), but it made me think there was very limited testing (it should have been easy to discover that the "m" flag doesn't work as advertised in most browsers). Other errors in the brushes (I think I encountered your double-word bug at one point, and a corner case with spacing that was really nasty) showed me that the library could indeed use a little work.

Still, I really like the ease of adding new brushes and some of the library's concepts and implementation, so here's hoping that the author gets a chance to improve it further.

"(it should have been easy to discover that the "m" flag doesn't work as advertised in most browsers)" --Me

To clarify, it actually does work "as advertised" in browsers which support it (JavaScript 1.5+), but the meaning is different than that which I think the author of dp.SyntaxHighlighter intended, based on the regex for multi-line comments shown above, and others throughout the various brushes. The m flag stands for Multiline Input, which makes "^" and "$" match at the beginning and end (respectively) of each line. However, it seems as if it was being used to mean "dot matches newline," which is certainly not what it does (and some of the regexes are flawed as a result).

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment