User forums > Using Code::Blocks
Conditional Code :: Blocks. highlighting in the editor
SmallTed:
Sorry
Maybe this is a trivial question.
I went back to code: blocks after four years.
And this is perhaps the main reason for my questions
I am trying to debug the program.
In the editor, is highlighted in the program code, depending on Conditional.
But not the one who should.
The example given shows where debugging.
The code in the editor should be highlighted, and it is not.
I can not control it.
Please help (links) explaining what I need to do to properly
were sublight space depending on the conditional
MortenMacFly:
Please search the forum before you ask, this has been answered many times.
Here the quick answer: This is a feature of the (3rd party) editor control we use (scintilla) which is far from being perfect. In fact, it works for simple cases, but mostly it fails. If you don't like it, please disable it in the editor options.
SmallTed:
Thanks for the answer,
Believe me that before I was looking for answers.
It was of course a lot but not to the point.
Only when you have entered a scintilla, I found a hint.
Search Google for example, will adjust to what before you scan for. That's why I could not get through the amount of information.
But I really thank you for the tip because I thought it was my fault or you need to set some parameters.
Is it possible to improve this tool because it is very useful for large projects
SmallTed
MortenMacFly:
--- Quote from: SmallTed on December 11, 2015, 09:29:34 pm ---Is it possible to improve this tool because it is very useful for large projects
--- End quote ---
Sure it is, but this is probably a question you should ask the scintilla maintainer or find out yourself (depending on your programming skills).
ollydbg:
There are several ideas to implement this feature(but that need some code changes in Scintilla's code base)
1, I see Huki try to implement this: see his commits: Scintilla: [huki] CB - support "grey out inactive" using CC plugin. and the following two commits. This is quite similar like the one Alpha try to make the variable highlight, see: CC based semantic highlight, I see that Alpha's code is not landed in our C::B's code base.
This kinds of methods is try to let scintilla call some function of our CC.
My idea is slightly different with Huki's, that is: CC can record all the #if xxx lines , and record all the calculated value of xxx in a database, either it is "true" or "false", and the scintilla just need to read the value, and see whether the next code need to be grayed out.
2, The method Alpha's added to our C::B's code base is try to set the keywords of the the member variables, such as the function in our C::B:
--- Code: ---void CodeCompletion::UpdateEditorSyntax(cbEditor* ed)
{
if (!Manager::Get()->GetConfigManager(wxT("code_completion"))->ReadBool(wxT("/semantic_keywords"), false))
return;
if (!ed)
ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!ed || ed->GetControl()->GetLexer() != wxSCI_LEX_CPP)
return;
TokenIdxSet result;
int flags = tkAnyContainer | tkAnyFunction;
if (ed->GetFilename().EndsWith(wxT(".c")))
flags |= tkVariable;
m_NativeParser.GetParser().FindTokensInFile(ed->GetFilename(), result, flags);
TokenTree* tree = m_NativeParser.GetParser().GetTokenTree();
std::set<wxString> varList;
TokenIdxSet parsedTokens;
CC_LOCKER_TRACK_TT_MTX_LOCK(s_TokenTreeMutex)
for (TokenIdxSet::const_iterator it = result.begin(); it != result.end(); ++it)
{
Token* token = tree->at(*it);
if (!token)
continue;
if (token->m_TokenKind == tkVariable) // global var - only added in C
{
varList.insert(token->m_Name);
continue;
}
else if (token->m_TokenKind & tkAnyFunction) // find parent class
{
if (token->m_ParentIndex == wxNOT_FOUND)
continue;
else
token = tree->at(token->m_ParentIndex);
}
if (!token || parsedTokens.find(token->m_Index) != parsedTokens.end())
continue; // no need to check the same token multiple times
parsedTokens.insert(token->m_Index);
for (TokenIdxSet::const_iterator chIt = token->m_Children.begin();
chIt != token->m_Children.end(); ++chIt)
{
const Token* chToken = tree->at(*chIt);
if (chToken && chToken->m_TokenKind == tkVariable)
{
varList.insert(chToken->m_Name);
}
}
// inherited members
if (token->m_Ancestors.empty())
tree->RecalcInheritanceChain(token);
for (TokenIdxSet::const_iterator ancIt = token->m_Ancestors.begin();
ancIt != token->m_Ancestors.end(); ++ancIt)
{
const Token* ancToken = tree->at(*ancIt);
if (!ancToken || parsedTokens.find(ancToken->m_Index) != parsedTokens.end())
continue;
for (TokenIdxSet::const_iterator chIt = ancToken->m_Children.begin();
chIt != ancToken->m_Children.end(); ++chIt)
{
const Token* chToken = tree->at(*chIt);
if ( chToken && chToken->m_TokenKind == tkVariable
&& chToken->m_Scope != tsPrivate) // cannot inherit these...
{
varList.insert(chToken->m_Name);
}
}
}
}
CC_LOCKER_TRACK_TT_MTX_UNLOCK(s_TokenTreeMutex)
EditorColourSet* colour_set = Manager::Get()->GetEditorManager()->GetColourSet();
if (!colour_set)
return;
wxString keywords = colour_set->GetKeywords(ed->GetLanguage(), 3);
for (std::set<wxString>::const_iterator keyIt = varList.begin();
keyIt != varList.end(); ++keyIt)
{
keywords += wxT(" ") + *keyIt;
}
ed->GetControl()->SetKeyWords(3, keywords);
ed->GetControl()->Colourise(0, -1);
}
--- End code ---
I see it just feed the "keywords" of the scintilla, and the scintilla will automatically highlight those words.
So, similar, we can feed the scintilla with another keywords(which is all the macro definitions). I see there is a page describe here: - http://www.scintilla.org/nulex.html
--- Code: ---lexer.cpp.track.preprocessor=1
lexer.cpp.update.preprocessor=1
keywords5.$(file.patterns.cpp)=\
PLAT_GTK=1 \
_MSC_VER \
PLAT_GTK_WIN32=1
...
--- End code ---
So, maybe, we need to feed the "keywords5" to scintilla with all the macros we get from the TokenTree.
As I see scintilla's some document: Upcoming 3.4.2 - Google Groups years ago, it said:
--- Quote ---C++ lexer understands more preprocessor statements. #if defined SYMBOL is understood. Some macros with arguments can be understood and these may be predefined in keyword set 4 (keywords5 for SciTE) with syntax similar to CHECKVERSION(x)=(x<3). Feature #1051.
--- End quote ---
So, we can let its C++ lexer to handle all the #if like preprocessor statements.
Any good ideas?
EDIT: it looks like the method 2 I said above do not need to change the scintilla's code base, right?
Navigation
[0] Message Index
[#] Next page
Go to full version