Editor question why some code is RED aka BAD

[neofight]

In using the Editor in the MPLAB IDE with the CCS PCWH compiler, I have noted that the red text is mapped to what the editor thinks is "bad" as listed in the choose color option on the TEXT tab of the properties dialog.

I've noted that the compiler works for #INCLUDES that show up in RED and for #includes that show up in BLUE, but that #FUSES or #fuses always shows in RED but appears to run OK.

I've found no posts that address this issue nor can I find a relevant help topic on the editor that deals with this issue.

Can anyone point me in the direction of a post or a help topic that actually goes into the whys and wherefores of the editor behavior. Knowing what to watch for and what to ignore would be most helpful in debugging problems such as tracing Error 23 problems in multiple compilation files.


Thanks for your consideration of this matter.

Neofight

[PCM programmer]

[neofight]

Thank you for your response PCM Programmer. On the surface, it would appear that that is what I may have meant, but in actuality, I could see that the MPLAB editor is not truly reflecting what is and what is not a syntax error. From what I've seen of the CCS compiler, it appears to be case insensitive in most cases. What I wanted to know was, has anyone gone to the trouble of documenting these departures from what one would expect in learning a new environment. I don't necessarily expect Microchip's free product to perfectly support any one of the many compilers it supports, I would just like to see an exception sheet that tells me to ignore the behaviour of this feature or that feature when using product X with this editor. My specific issue is that in trying to break out my beta all-in-one program to sub modules of .c and .h files, that the red lined items in each of the files begs the question: should I pay attention to this or ignore it. This in addition to all the misteaks that a beginner makes and has to resolve when taking on such a task for the first time in a new environment. I will of course prevail eventually, but it might be faster if I wasn't trying to treat non-problems because the editor marked them as BAD in their presentation to the user. If there isn't such a resource, then I guess I should move to rectify that and share it, but not before finishing this project I am working on. And thanks for the link by the way.

have a great day,

Neofight

[PCM programmer]

I think I understand your problem. The MPLAB syntax coloring
algorithm doesn't understand CCS extensions to the preprocessor,
such as:

[neofight]

I too didn't notice the difference at first because the program build was progressing without many errors. I learned about the colour scheme when I went to change the ASCII characters to a black background so you can see the awful default light blue. That's when I noticed that the only colour red was used for is what they referred to as BAD. I then played around with upper and lower case on the #include and found that it went from blue for lower case to red for upper case, but it made no difference to the compilation.

I know this is a niggly point, but the instructor in me thought that for neophytes, that have had no prior exposure to editors and compilers, might be thrown by this. I like your idea of changing all the reserved words to red though. Its a good interim measure.

In a few weeks when I'm done this project I will find the time to put together a blurb on this and post it on my server as a down-loadable doc file and post a link to it in this forum. If Microchip does read these posts, then perhaps they can consider adding it to their revision list to either add better user customization or fix the editor so it shows blue (normal) for all the pre processor directives that are valid and are in lower case.
CCS could also clean up their docs to reflect whatever the convention is for upper or lower case in their list of options and the examples that they show in the manual. Issues like these confuse learners.

The convention seems to be lower case for statements and pre-compiler directives, with upper case used for constants, and variables. The compiler doesn't seem to care if they are upper or lower case, as long as the case matches for the constants and variables, and that they are not mixed between declaration (and or assignment) and their use in the program. I'll put thIs on my sOmEtHiNg to check out list and report back later. If you look at the CCS manual on say the rs232 Pre-Processor Directives section you will see options listed in upper case, yet shown in the examples as lower case. I know I'm niggling again, but we teach college students to be precise in their use of the language for reports and letters with style manuals such as the American Psychological Association (APA) manuals. Where is the APA manual for compilers? But I digress, it is getting late and I have to get back to coding. Its been a slice corresponding with you on this matter.

Have a pleasant evening, morning, day, or whatever.

neofight

[PCM programmer]

The CCS compiler is case insensitive by default. This is different from
most other compilers. You can tell it to be case sensitive by putting
this statement near the start of your program:

[neofight]

Thank you PCM Programmer. I think I will use the case sensitivity mode to maintain code consistency. And I will check out the references to code style you provided. Many thanks for the prompt response.

Best regards,

neofight