Copy MPLAB C code with syntax color

[3v0]

For people working on documentation involving MPLAB I have a tip.

When you cut code displayed in MPLAB's editor window and paste it into another application you lose the syntax coloring.

Visual Studio C++ 2008 Express Edition provides a close match to what MPLAB uses and it does not have this problem. So far I have noticed the the filename in #include is the wrong color as are binary constants.

Visual Studio may have setting where you can set the coloring to match MPLAB more closely.

You have to be willing to install Visual Studio. If you do you can use it to do a nice job of reformating you code and several other things which MPLAB is lacking. Worth the trip if your programs are non trivial.

 

[Torben]

Hi 3V0,

I'm a little confused--you're making it sound almost like the colouring is somehow intrinsic to the code itself. I mean, how can the colour of an #include statement be "wrong" when it's totally up to the editor what colour to display it with?

I'm also not sure about the implication that code copied from Visual Studio will take its colour information along with it. I can see if it's pasted into another syntax-colouring text widget that the new widget might apply its own code colouring, and perhaps MS apps use a .NET trick to bring style information along with the code, but that's not the same thing. If I copy code from VS into emacs, I will get the emacs-defined syntax highlighting and the old VS highlighting is lost.

What am I missing here?


Torben

 

[bananasiong]

Hi,
3v0 is right. When you paste the C code from some resource into MPLAB editor, the color can be wrong. I've got it green color which is like the code being commented, but in fact it is not commented.

 

[Torben]

Hi,
3v0 is right. When you paste the C code from some resource into MPLAB editor, the color can be wrong. I've got it green color which is like the code being commented, but in fact it is not commented.

I know that, but what I'm saying is that code has no colour. On my editors, strings are green, compiler directives are rust-red, comments are gray, etc. If I then take that code and paste it into another editor and the colours are different, that doesn't mean the colours are "wrong", just that the syntax highlighting engine in that editor isn't set up the way I like it. Most editors allow you to define the colours for each syntactic class.

There is no standard for code highlighting, and no reason at all that comments should be green (or purple, or mauve) beyond personal preference.


Torben

 

[3v0]

I never expected a reply. The confusion is about context and sketchy details on my part. But I did say it was about documentation.

Hi 3V0,

I'm a little confused--you're making it sound almost like the colouring is somehow intrinsic to the code itself. I mean, how can the colour of an #include statement be "wrong" when it's totally up to the editor what colour to display it with?

I am doing entry level tutorials and I needed the code in the text to match what the user sees down to the syntax coloring.​

I'm also not sure about the implication that code copied from Visual Studio will take its colour information along with it.

It is true. When you cut from Visual Studio and paste into Open Office Write the color comes along with the text. You have to cut the text from a app that passes the color with the cut and you have to paste it to an app that understands the color info.
​

Torben

Open Office Write does a nice job of generating PDFs too.

 

[Torben]

I never expected a reply. The confusion is about context and sketchy details on my part. But I did say it was about documentation.

Open Office Write does a nice job of generating PDFs too.

OK, I see what you're saying. VS does then do some behind-the-scenes jiggery-pokery to include style information.

I was just thinking that new users might become confused and think that there was some kind of syntax highlighting standard or that the highlighting was somehow intrinsic to the code.


Torben