This is feature enhacement issue to differentiate code segments written in C/C++, when they are turned off by preprocessing directive such as `#if`, `#ifdef`, `#ifndef`, etc. An example may look like:
``` #if 0 /* code temporally turned off */ int Values[] {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}; size_t Counter = std::end(Values) - std::begin(Values); int n = 5; /* number of items per column to display */
for (int k = 0; k < Counter; k++) cout << Values[k] << " " << (((k+1) % n) ? ' ' : '\n'); #endif ```
This feature is already supported by Vim, Visual C++, Clion and Gedit, Pluma, among others. thus I think it is worth to implement. I particularly like the VC++ 2015's behavior, which is to use the same colors as normal, but with lower contrast (i.e. they are faded).
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047
Scintilla already supports this through the lexer property `lexer.cpp.track.preprocessor=1` However, this adds another 64 styles Geany doesn't set by default, but I hacked a little plugin to do just that a while ago, using lighter variants of the non-disabled styles. The plugin is unpolished (full of test code and alike), but I published it just now so you can try it out, improve it or whatever fits you: https://github.com/b4n/geany-c-preproc-hl
Hope it helps.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222382358
What about this?
```c // in foo.h #define ONE 1
// in bar.h #include "foo.h" #if ONE static const int enabled_code = 42; #endif ```
Could CTags be used to make it work correctly?
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222392883
As @codebrainz pointed out, Scintilla uses preprocessor directives to decide whether a code block is enabled or not. This is easy for `#if 0`s, but a lot trickier for less obvious directives, like `#if ONE`, where Scintilla has to know the value of `ONE` to decide -- and it assumes any unknown evaluate to false, so would disable the `#if ONE` case.
To get better results, yes, CTags could be used. Scintilla's C lexer has a set of keywords used for predefined preprocessor definitions (set n°4, "Preprocessor definitions"), that can be filled with `definition[=value]` entries. A plugin could update those keywords from the tagmanager's workspace tags to help Scintilla make the right choice.
An alternative could be proposing an alternative, dumber, preprocessor parser for the Scintilla lexer, that would only look out for literal values for disabling parts, with `#if 0` or `#if 1`. That would have to be submitted to Scintilla.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222461094
Tentative impl in https://github.com/b4n/geany-c-preproc-hl/commit/c8e032341dd07c27f0d3bd83bea...
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222498162
There's also stuff that is implicitly defined and/or defined on the command line by the build system, for example `#if __cplusplus >= 201402L` or `-DNDEBUG`.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222503017
sure. Those can be fixed by allowing an extra user-provided list, or knowing about the build system.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222503970
Of course lots of macros are defined in a header so the ctags would have to parse the includes as well.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222565175
@elextr well… not any more or less than for tags in general IMO, so tags files and plugins like Project Organizer seem good enough to me in that regard.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222691882
They are not really "good enough" when they parse files that are not meant to be included together and get very confused, but thats not part of this issue.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222847272
This feature is far more useful if it works properly like it does in IDEs with compiler/build support like QtCreator or VisualStudio. If it only works "sometimes" it just seems buggy, IMO.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222859057
Yes, as @codebrainz points out we have to either know about the builds like the heavyweight IDEs do, or its flakey, I stopped using the project plugins because they caused variables that have the same name as types to be highlighted even if the file defining the type is never visible where the variable is used, and when a configuration is chosen by a define the symbols from *both* choices are included and so its confused.
Overall its better not to offer things that only partly work.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222863499
Closed #1047.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#event-678105158
I agree with @codebrainz's point. The fully reliable mechanism would require implicit knowledge of the toolchain. Besides compiler's predefined macros (e.g. https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html), there are language macros, which values can vary depending upon which language standard is selected (e.g. C90/C99/C11) and I think this is outside of scope of lighweight IDE.
I am not sure if it is worth to handle `#if 0` case alone or maybe narrow `#ifdef`s just to single translation unit, as already pointes by @elextr such partially working feature may be misleading and at the end do more harm than it is worth.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-222930212
Reopened #1047.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#event-678105471
That plugin works perfectly. Exactly what I was looking for - thank-you!
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#issuecomment-223819483
Closed #1047.
--- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1047#event-741552078
github-comments@lists.geany.org