Two problems with r8232

[oBFusCATed]

I've just updated to r8232 and there are two problems:
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.
    The preview in the syntax highlight settings panel looks correct. Also removing the default.conf makes this problem go away.


2. Just tested to remove the default.conf file and I've got a pleasant red surprise:


I have no time to investigate what is causing this issues, so I'll be happy if someone does it for me :-P
My previous revision was 8164.

p.s. do we need to store the recent file/project list in the default.conf file? Should this is save in another file?

[Alpha]

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).
In the XML compiler branch, this dialog has been modified so that (among other things) detected compilers are not erroneously highlighted.

[oBFusCATed]

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).
In the XML compiler branch, this dialog has been modified so that (among other things) detected compilers are not erroneously highlighted.

Is this (the red backgrounds) some new feature as I've never seen in before?
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.

[Alpha]

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!

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.)

Is this (the red backgrounds) some new feature as I've never seen in before?
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.

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...

[Alpha]

sdk/editorcolourset.cpp, line 521

Code

    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?
[...]

[oBFusCATed]

Alpha: Probably you have to look what is happening in the load function, not in the save function.

[Alpha]

I guess I was not quite clear.
Line 652

Code

        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);
        }

The only way this loading function could be adapted (because OptionColour's are saved numerically) is if it had manually created remap database, and even then, it would only work if it knew which versions it was mapping from->to.  Does Code::Blocks have a method by which it can retrieve the previous version number default.conf was saved with?

[oBFusCATed]

So, I guess, the changes to the lexer have to be reverted, as I predict massive amount of unhappy users attacking the forum.

btw: What do I need to do in order to fix my syntax highlight?

p.s. probably the new styles should be save in newer, better way, but the old should be kept as they are.

[MortenMacFly]

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...?!

[oBFusCATed]

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.

[Pecan]

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.

I also completely lost my custom editor highlighting with the current SVN.
Every color I'd previously set was now a different color. This was/is a hugh pain in the butt. I finally gave up on attempting to save my color scheme and deleted the .conf, starting over again.

[Alpha]

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:

rev8230 shifts many of the items in the C/C++ lexer [...]

Specifically:

Code

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

The change made here enables code that is greyed out by preprocessor commands to still be syntax highlighted (previously it all just turned black).
(This does, in my opinion, make code much more readable, however) In order to achieve it, I had to add many new sections to lexer_cpp.xml.  The addition of new sections means that loading custom color schemes (by the current system) will apply the saved data to the wrong sections (due to the offset).

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.
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.

[MortenMacFly]

Sorry.
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.

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.

Now I also understand why I don't see it. I don't have custom syntax highlighting - so I was just seeing the improvement.

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.

[oBFusCATed]

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.
If there is no plan for a nightly and you plan to fix it in the next couple of weeks, I'm OK with not reverting it.

Funnily, I thought, I have not modified my highlighting, but I carry my home dir with all the upgrades/reinstalls, so I might have some changes done many years ago.

[oBFusCATed]

BTW: Is there any reason that the syntax highlight preview looks correct, so the code is different, I think this is pretty bad, don't you think so?