1. Suddenly the default color for everything is gray instead of black. I don't know why this happens, but I've not modified colors in the 2-3 year or at all.Sorry, I really need to stop messing with the lexer :). I rev8230 shifts many of the items in the C/C++ lexer, so if the default.conf has any saved color schemes, it is unlikely to load them correctly. (PS: try the new check boxes under C++ editor settings.)
2. Just tested to remove the default.conf file and I've got a pleasant red surprise:Code::Blocks always highlights items in red if at the point of loading, their master paths are empty (which they all are when a new profile is started).
Sorry, I really need to stop messing with the lexer :). I rev8230 shifts many of the items in the C/C++ lexer, so if the default.conf has any saved color schemes, it is unlikely to load them correctly. (PS: try the new check boxes under C++ editor settings.)I don't know the details, but you must make sure that current profiles work as before or we will get tons of people complaining about it!
Code::Blocks always highlights items in red if at the point of loading, their master paths are empty (which they all are when a new profile is started).Is this (the red backgrounds) some new feature as I've never seen in before?
In the XML compiler branch, this dialog has been modified so that (among other things) detected compilers are not erroneously highlighted.
I will explore it to see if there is anything that can be done, however to my current knowledge, the way custom color schemes are saved would make this extremely difficult to create an automatic upgrade. (I could be wrong on this.)Sorry, I really need to stop messing with the lexer :). I rev8230 shifts many of the items in the C/C++ lexer, so if the default.conf has any saved color schemes, it is unlikely to load them correctly. (PS: try the new check boxes under C++ editor settings.)I don't know the details, but you must make sure that current profiles work as before or we will get tons of people complaining about it!
Is this (the red backgrounds) some new feature as I've never seen in before?It has been in there at least since the last stable (two years ago), and probably longer. The modifications in the XML compiler branch are a little more friendly; even there, however, more needs to be done...
I don't think this is something that is user friendly, so it needs to be fixed or at least it needs to be made a bit less disturbing and a bit more clear.
for (OptionSetsMap::iterator it = m_Sets.begin(); it != m_Sets.end(); ++it)
{
if (it->first == HL_NONE || it->first == HL_AUTO)
continue;
wxString lang = it->first;
bool gsaved = false;
key.Clear();
key << _T("/colour_sets/") << m_Name << _T('/') << lang;
for (unsigned int i = 0; i < it->second.m_Colours.GetCount(); ++i)
{
OptionColour* opt = it->second.m_Colours.Item(i);
wxString tmpKey;
tmpKey << key << _T("/style") << wxString::Format(_T("%d"), i); // <-- how can something saved numerically be auto-magically updated?
[...]
for (unsigned int i = 0; i < it->second.m_Colours.GetCount(); ++i)
{
OptionColour* opt = it->second.m_Colours.Item(i);
if (!opt)
continue;
wxString tmpKey;
tmpKey << key << _T("/style") << wxString::Format(_T("%d"), i); // <-- remap required here
if (cfg->Exists(tmpKey + _T("/name")))
opt->name = cfg->Read(tmpKey + _T("/name"));
else
{
// make sure we didn't create it accidentally
cfg->DeleteSubPath(tmpKey);
continue;
}
if (cfg->Exists(tmpKey + _T("/fore")))
opt->fore = cfg->ReadColour(tmpKey + _T("/fore"), opt->fore);
if (cfg->Exists(tmpKey + _T("/back")))
opt->back = cfg->ReadColour(tmpKey + _T("/back"), opt->back);
if (cfg->Exists(tmpKey + _T("/bold")))
opt->bold = cfg->ReadBool(tmpKey + _T("/bold"), opt->bold);
if (cfg->Exists(tmpKey + _T("/italics")))
opt->italics = cfg->ReadBool(tmpKey + _T("/italics"), opt->italics);
if (cfg->Exists(tmpKey + _T("/underlined")))
opt->underlined = cfg->ReadBool(tmpKey + _T("/underlined"), opt->underlined);
if (cfg->Exists(tmpKey + _T("/isStyle")))
opt->isStyle = cfg->ReadBool(tmpKey + _T("/isStyle"), opt->isStyle);
}
btw: What do I need to do in order to fix my syntax highlight?I still don't get what the problem is here really., I don't have such issue - it works just fine. What modifications are we talking about? There is no new functionality in the editor's "Syntax highlight" options...?!
I still don't get what the problem is here really., I don't have such issue - it works just fine. What modifications are we talking about? There is no new functionality in the editor's "Syntax highlight" options...?!The problem is that between 8164 and 8232 something changed and now some strings are gray instead of black as they were before the upgrade.
I still don't get what the problem is here really., I don't have such issue - it works just fine. What modifications are we talking about? There is no new functionality in the editor's "Syntax highlight" options...?!The problem is that between 8164 and 8232 something changed and now some strings are gray instead of black as they were before the upgrade.
I have no time to bisect it to find the wrong revision, unfortunately.
It happened here:I still don't get what the problem is here really., I don't have such issue - it works just fine. What modifications are we talking about? There is no new functionality in the editor's "Syntax highlight" options...?!The problem is that between 8164 and 8232 something changed and now some strings are gray instead of black as they were before the upgrade.
I have no time to bisect it to find the wrong revision, unfortunately.
rev8230 shifts many of the items in the C/C++ lexer [...]Specifically:
http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=/trunk/src/sdk/resources/lexers/lexer_cpp.xml@8229&compare[]=/trunk/src/sdk/resources/lexers/lexer_cpp.xml@8230
So, I guess, the changes to the lexer have to be reverted, as I predict massive amount of unhappy users attacking the forum.
I also completely lost my custom editor highlighting with the current SVN.Sorry.
Sorry.Thanks for the explanation. Its not nice, but actually the wrong part is the loading of the lexers. I guess we will change these lexer files form time to time and as I understand everytime we do so, the custom syntax highlighting will be broken.
I think a temporary partial revert of the file src/sdk/resources/lexers/lexer_cpp.xml might be the best option. I have an idea that could resolve this issue, but it may be some time before I have a working patch.
So the question is: Shall we really revert, or actually fix the loading? Nevertheless fixing the loading might not mean to necessarily also update old schemes though. :-\If you plan to have a nightly build, before this problem is fixed, you'll have to revert it as there will be many people which will suffer and many people will complain, so the will put some suffering on our shoulders.
Index: src/sdk/cbeditor.cpp
===================================================================
--- src/sdk/cbeditor.cpp (revision 8236)
+++ src/sdk/cbeditor.cpp (working copy)
@@ -1576,7 +1576,7 @@
ConfigManager* mgr = Manager::Get()->GetConfigManager(_T("editor"));
// Interpret #if/#else/#endif to grey out code that is not active
- control->SetProperty(_T("lexer.cpp.track.preprocessor"), mgr->ReadBool(_T("/track_preprocessor"), false) ? _T("1") : _T("0"));
+ control->SetProperty(_T("lexer.cpp.track.preprocessor"), mgr->ReadBool(_T("/track_preprocessor"), true) ? _T("1") : _T("0"));
// code folding
if (mgr->ReadBool(_T("/folding/show_folds"), true))
Index: src/sdk/editormanager.cpp
===================================================================
--- src/sdk/editormanager.cpp (revision 8236)
+++ src/sdk/editormanager.cpp (working copy)
@@ -3045,8 +3045,8 @@
{
cbProject* prj = Manager::Get()->GetProjectManager()->GetActiveProject();
if ( !prj
- || !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/track_preprocessor"), false)
- || !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/collect_prj_defines"), false) )
+ || !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/track_preprocessor"), true)
+ || !Manager::Get()->GetConfigManager(wxT("editor"))->ReadBool(wxT("/collect_prj_defines"), true) )
{
event.Skip();
return;
@@ -3067,13 +3067,39 @@
lst = &prj->GetFilesList();
id = prj->GetCompilerID();
}
+ Compiler* comp = CompilerFactory::GetCompiler(id); // get global flags
+ if (comp)
+ AppendArray(comp->GetCompilerOptions(), compilerFlags);
wxArrayString defines;
for (size_t i = 0; i < compilerFlags.Count(); ++i)
{
- if ( (compilerFlags[i].Left(2) == wxT("-D"))
- || (compilerFlags[i].Left(2) == wxT("/D")) )
+ if ( compilerFlags[i].StartsWith(wxT("-D"))
+ || compilerFlags[i].StartsWith(wxT("/D")) )
+ {
defines.Add(compilerFlags[i].Mid(2));
+ }
+ else if ( compilerFlags[i].StartsWith(wxT("`"))
+ && compilerFlags[i].EndsWith(wxT("`")) )
+ {
+ wxArrayString out;
+ long ret = 0;
+ {
+ wxLogNull logNo; // no need to warn if execution fails
+ ret = wxExecute(compilerFlags[i].Mid(1, compilerFlags[i].Length() - 2), out);
+ }
+ if (ret == 0)
+ {
+ out = GetArrayFromString(out[0], wxT(" ")); // pkg-config gives only single line output
+ AppendArray(out, compilerFlags); // append for processing
+ }
+ }
+ else if ( compilerFlags[i] == wxT("-ansi")
+ || compilerFlags[i] == wxT("-std=c90")
+ || compilerFlags[i] == wxT("-std=c++98"))
+ {
+ defines.Add(wxT("__STRICT_ANSI__"));
+ }
}
defines.Add(wxT("__cplusplus"));
Index: src/sdk/editorcolourset.cpp
===================================================================
--- src/sdk/editorcolourset.cpp (revision 8236)
+++ src/sdk/editorcolourset.cpp (working copy)
@@ -658,7 +658,22 @@
tmpKey << key << _T("/style") << wxString::Format(_T("%d"), i);
if (cfg->Exists(tmpKey + _T("/name")))
- opt->name = cfg->Read(tmpKey + _T("/name"));
+ {
+ wxString name = cfg->Read(tmpKey + _T("/name"));
+ for (size_t j = 0; opt->name != name && i + j < it->second.m_Colours.GetCount(); ++j) // search forwards first
+ {
+ opt = it->second.m_Colours.Item(i + j);
+ }
+ for (int j = -1; opt->name != name && i + j >= 0; --j) // then search backwards if it was not found
+ {
+ opt = it->second.m_Colours.Item(i + j);
+ }
+ if (opt->name != name)
+ {
+ cfg->DeleteSubPath(tmpKey); // unknown key, clear it out
+ continue;
+ }
+ }
else
{
// make sure we didn't create it accidentally
Index: src/sdk/editorconfigurationdlg.cpp
===================================================================
--- src/sdk/editorconfigurationdlg.cpp (revision 8236)
+++ src/sdk/editorconfigurationdlg.cpp (working copy)
@@ -140,8 +140,8 @@
XRCCTRL(*this, "cmbViewWS", wxComboBox)->SetSelection(cfg->ReadInt(_T("/view_whitespace"), 0));
XRCCTRL(*this, "rbTabText", wxRadioBox)->SetSelection(cfg->ReadBool(_T("/tab_text_relative"), true)? 1 : 0);
- XRCCTRL(*this, "chkTrackPreprocessor", wxCheckBox)->SetValue(cfg->ReadBool(_T("/track_preprocessor"), false));
- XRCCTRL(*this, "chkCollectPrjDefines", wxCheckBox)->SetValue(cfg->ReadBool(_T("/collect_prj_defines"), false));
+ XRCCTRL(*this, "chkTrackPreprocessor", wxCheckBox)->SetValue(cfg->ReadBool(_T("/track_preprocessor"), true));
+ XRCCTRL(*this, "chkCollectPrjDefines", wxCheckBox)->SetValue(cfg->ReadBool(_T("/collect_prj_defines"), true));
XRCCTRL(*this, "chkPlatDefines", wxCheckBox)->SetValue(cfg->ReadBool(_T("/platform_defines"), false));
XRCCTRL(*this, "chkColoursWxSmith", wxCheckBox)->SetValue(cfg->ReadBool(_T("/highlight_wxsmith"), true));
BTW: Is there any reason that the syntax highlight preview looks correct, so the code is differentI have no idea how this happens (and I cannot reproduce it).
This patch should fix (almost) all custom color scheme loading problems. [...]An exec command every time? Couldn't this be at least cached? Maybe that should even be a function of the compiler... (not a specific one, but the compiler framework. Because the compile has to do it, too IIRC... (I want to avoid having duplicate code.)Code+ ret = wxExecute(compilerFlags[i].Mid(1, compilerFlags[i].Length() - 2), out);
Alpha: it is considered a good style separating changes in different patches/commits as this makes reviewing it easier. And it they are committed separately the svn blame will be more useful at a later time.Huh? This patch is needed in one to work. There is nothing to separate, or what did you mean? Collecting preprocessor defines is needed fr the highlighting function to work correctly.
This patch should fix (almost) all custom color scheme loading problems.Never mind; it only worked by a fluke.
I had misunderstood the way color schemes were loaded/saved. Items with multiple indexes are actually saved once for each index, which is why the preview looked different than the actual code. The preview reinitialized all the values, however the actual code loaded (in this case) style "Comment (normal)" into the second index (11) that I added to "Default".BTW: Is there any reason that the syntax highlight preview looks correct, so the code is differentI have no idea how this happens (and I cannot reproduce it).
An exec command every time? Couldn't this be at least cached? Maybe that should even be a function of the compiler... (not a specific one, but the compiler framework. Because the compile has to do it, too IIRC... (I want to avoid having duplicate code.)Right; I just noticed this now makes switching build targets a little slow.
Huh? This patch is needed in one to work. There is nothing to separate, or what did you mean? Collecting preprocessor defines is needed fr the highlighting function to work correctly.Sorry, but the patch explanation made me believe the patch can be applied in two steps and there are some optional parts.
My fault; I failed to describe the connection to the original patch (which inadvertently caused the problems).Huh? This patch is needed in one to work. There is nothing to separate, or what did you mean? Collecting preprocessor defines is needed fr the highlighting function to work correctly.Sorry, but the patch explanation made me believe the patch can be applied in two steps and there are some optional parts.