Page 1 of 1
#ifdef block coloring
Posted: Wed Apr 02, 2014 7:15 pm
by petah
Hi Eran,
I'm using fresh builds of CL + wx from a couple days ago and the #ifdef blocks are not getting grayed-out correctly. I tried defining the preprocessor symbol in the project as well as in the source code. Is there a way to debug how preprocessors are being defined prior to syntax coloring?
Alternatively, would it be possible to have different block colorings (instead of greyed-out) so you can identify different code blocks but they're all still readable?
thx & cheers,
-- p
Re: #ifdef block coloring
Posted: Wed Apr 02, 2014 8:20 pm
by eranif
petah wrote:'m using fresh builds of CL + wx from a couple days ago and the #ifdef blocks are not getting grayed-out correctly
Can you define what does "correctly" means?
I had plans on fixing this, but it was put aside in favour of the other big task I am working on it atm (LLDB)
Eran
Re: #ifdef block coloring
Posted: Wed Apr 02, 2014 8:43 pm
by petah
eranif wrote:petah wrote:I'm using fresh builds of CL + wx from a couple days ago and the #ifdef blocks are not getting grayed-out correctly
Can you define what does "correctly" means?
Currently the syntax highlighter reflects the opposite state of the preprocessor constant, i.e. I define SEQUENCER in the project setttings but code blocks surrounded by #ifdef SEQUENCER are grayed-out (which would be incorrect). In fact the lexer state seems random as it changes during editing.
eranif wrote:
I had plans on fixing this, but it was put aside in favour of the other big task I am working on it atm (LLDB)
Haha you're putting me on the spot - I take it you still can't reproduce yourself by molecular division
Thx again,
-- p
edit: come to think of it, it could be a scintilla bug
Re: #ifdef block coloring
Posted: Wed Apr 02, 2014 9:02 pm
by petah
some more info:
I can reproduce an "impossible" case, with a code block like:
Code: Select all
#ifdef MYDEFINE
// case 1
#else
// case 2
#endif
when I change the 1st line to "#if
ndef MYDEFINE", then back to "#ifdef MYDEFINE", neither case1 nor case2 will be grayed-out. Maybe scintilla reports a parsing error?
thx again,
-- p
Re: #ifdef block coloring
Posted: Wed Apr 16, 2014 2:36 am
by petah
Hi Eran,
I'm pretty sure this is a scintilla regression because it never used to see it behave so crazy. It used to work fine even around C++11 raw strings but now can't process a single one:
syntax_color_raw_string.png
I'm not sure yet that raw strings are the only cause of the bug yet, I'll have to confirm it only shows when there's some raw string used in upstream headers and otherwise does not.
thx & cheers,
-- p
Re: #ifdef block coloring
Posted: Wed Apr 16, 2014 9:18 am
by eranif
Is this with wxTrunk? what about wx3.0?
Eran
Re: #ifdef block coloring
Posted: Wed Apr 16, 2014 10:13 am
by petah
that was with a wx build from April 10, I didn't see changes related to wxSTC after that but I can retry with fresh builds if you want.
-- p