different Color Lexer keyword

General questions regarding the usage of CodeLite
n60b
CodeLite Curious
Posts: 2
Joined: Sun Apr 01, 2018 1:56 pm
Genuine User: Yes
IDE Question: ino
Contact:

different Color Lexer keyword

Post by n60b » Sun Apr 01, 2018 2:06 pm

Hello,
I use Codelite C++ in parallel with the Arduino IDE and I was wondering if it was possible to implement it in C ++ preferences
(Styles) different colors for the 4 Lexer keyword sets
Thanks, Nicola

User avatar
eranif
CodeLite Plugin
Posts: 5995
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: different Color Lexer keyword

Post by eranif » Mon Apr 02, 2018 10:00 am

I am not sure I understand what you are trying to do.
Can you please provide an example?
Make sure you have read the HOW TO POST thread

n60b
CodeLite Curious
Posts: 2
Joined: Sun Apr 01, 2018 1:56 pm
Genuine User: Yes
IDE Question: ino
Contact:

Re: different Color Lexer keyword

Post by n60b » Tue Apr 03, 2018 12:49 am

I expressed my question partially and badly ... I try again:
to make the listing more understandable and therefore "repairable" I think two things would be useful:
1-be able to give a group of keywords (eg tft serial) a color, so for example tft.xxx would identify functions towards the display, serial.xxx towards the USB-PC serial, etc.
2-compressing comments ... in listings with many nested conditions, multiline comments
complicate the understanding of the same and its modification / correction errors
to be able to display the 1st line of the commentary on the right-hand side of the instruction line and expand it like a comic with the mouse over it (always the least invasive comic, like multiline window but always on the right of the listing) would simplify the life, I think ...
Codelite on Arduino allows me to break down the listing into multiple modules .ino
and quickly ascend to the function used for example in the X1.ino module but implemented in the Y1.ino module
being able to color the names of specific functions (serial, clock, etc.) makes them visually more "detectable", and to be able to concentrate on the listing knowing that the comments are present but hidden / not invasive but quickly viewable / editable would help a lot ...
I know I am a heretic, but in complex cases, using #DEFINE, in "pushed" nidifications, substituting "if (" with "SE" (Italian), ") {" with "ALLORA", etc ... BASICING the C, relying on the display allowed by "TAB" rather than "{}", I find it easier to turn the idea into execution and find errors ...
certainly sharing software that uses different "human" languages ​​would require a "translator"
but:
#define SE ; if (
#define ALLORA ) {
#define FINE_SE ;}
IF (x1 == 5) {
a = 5;
}
"sounds" different from
SE x1 == 5 ALLORA
a = 5
FINE_SE
certainly the first is more "compact" and "universal", but the second I understand it at a glance,
especially in cases with several nested conditions the idea of ​​what the program does is immediate
and the compiler "digests" it as C ...
Add to this:
- different colors for particular key words that recall "important" functions of the program and
- be able to concentrate on the listing having the comments (indispensable for the understanding in later moments of the same) present but hidden or not invasive
Well ... I have no words !!!
Nicola

Post Reply