The 27 July 2009 build (5716) is out.

[jens]

which is a change to 'compilercommandgenerator.cpp' base upon work of 'Biplab' : "replace macros for compiler options".
Basically 2 lines have been added, doing a macro substitution, could it be it is carried out too early ??

It seems so.

In ReplaceMacros, we replace macros and environment-variables.
Our internally used variables have the same format as the unix/linux shell-variables (if used without braces), so they get replaced by the appropriate environment variable, but such a variable does not exist, so we get an empty string instead.

ReplaceMacros should be called after our variables get expanded, not before.

EDIT:

and as I just saw, ReplaceMacros is called at the  end GenerateCommandline, so it I do not think, that there is any cause to call it so early as we do it in the moment (after the changes in commit 5636.
There might be a problem , if a user tries to add C::B variables with a script, but that does not work anyway (unless they are added with two $'s), because the variables get expanded after the scripts.

So my proposal is to revert commit 5636, unless we find a way to protect C::B's internal variables.

[MortenMacFly]

So my proposal is to revert commit 5636, unless we find a way to protect C::B's internal variables.

Agreed. Still: It works for me on Windows even with the patch!!!

EDIT: I've taken the action accordingly.

[sbilsing]

The workaround to double the $ works for me, too.
I should have mentioned, that I use the macro in the project's compiler settings, not in the global compiler settings. In the global settings everything seems fine.

[MortenMacFly]

In the global settings everything seems fine.

Now THAT clarifies why it seemed to work for me.

[sdfwds4]

brace completion is good, i like it, thank you!

[Biplab]

which is a change to 'compilercommandgenerator.cpp' base upon work of 'Biplab' : "replace macros for compiler options".
Basically 2 lines have been added, doing a macro substitution, could it be it is carried out too early ??

I can't access Berlios at the moment. So I'm unable to shed more light on this. Anyway it's already been reverted and I'll see if the earlier patch can be improved or not.

[stahta01]

Link to check berlios status
http://monitor.berlios.de/berlios-status/index.php

Tim S

[vix]

Sorry for my insistence,...
only to be sure that someone could confirm the File Encoding problem (see my previous post).
I can't use C::B anymore in this situation because all the characters like à, è, ò, ... are messed up.
And my C/C++ comments are full of them because they're quite common in Italian language (but I think also in French, Spanish, ...)

At the end I had to switch back to the old 5678 Nightly Build, but if I made some mistake during upgrading I could try to solve it....

Thanks for your help

[ollydbg]

Sorry for my insistence,...
only to be sure that someone could confirm the File Encoding problem (see my previous post).
I can't use C::B anymore in this situation because all the characters like à, è, ò, ... are messed up.
And my C/C++ comments are full of them because they're quite common in Italian language (but I think also in French, Spanish, ...)

At the end I had to switch back to the old 5678 Nightly Build, but if I made some mistake during upgrading I could try to solve it....

Thanks for your help

Because the latest two version of night build uses a mozilla file encoding detection scheme, so, it works better than the old 5678 in my Chinese system.

Not sure it works badly in your system.

[jens]

Sorry for my insistence,...
only to be sure that someone could confirm the File Encoding problem (see my previous post).
I can't use C::B anymore in this situation because all the characters like à, è, ò, ... are messed up.
And my C/C++ comments are full of them because they're quite common in Italian language (but I think also in French, Spanish, ...)

At the end I had to switch back to the old 5678 Nightly Build, but if I made some mistake during upgrading I could try to solve it....

Thanks for your help

I can confirm this (on wondows), and will have a look into it.
The encoding detection has also changed with the change to wxAui.

[jens]

@vix:
could you please send me example-files that fail, if possible ?
see: http://forums.codeblocks.org/index.php/topic,10191.msg70572.html#msg70572
Files with extremly less (non-ascii) characters are always hard to decode.

It might help to switch to multibyte-encoding (utf-8), if this is a legal alternative.

[vix]

could you please send me example-files that fail, if possible ?

just sent

[jens]

could you please send me example-files that fail, if possible ?

just sent

The reason is quite simple, I decided to also search for latin-2 encoding needed for langauges like Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (when in the Latin script), Slovak, Slovenian, Upper Sorbian, and Lower Sorbian, but it breaks some latin-1 encoded texts due to their similarity, not all and not always (depending of the used characters).
FireFox 3.5 still does not automatically detect these languages correctly (at least not in all cases).

I think I will add a configuration-option that the user can decide whether he/she wants to try to detect latin-2 also (with a hint, that it might break latin-1 detection).

I don't know a better solution, the alternative would be either not to detect latin-2 or some latin-1 encodings.

By the way: I did not stumble over the problem, because if you use german umlauts (äöü) or the german sharp s (ß), even single-byte texts are detected correctly, but I use utf-8 in almost any cases anyways (except for at work where I have to use windows tools, that do not all work with unicode correctly).

[vix]

The reason is quite simple, I decided to also search for latin-2 encoding needed for langauges like Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (when in the Latin script), Slovak, Slovenian, Upper Sorbian, and Lower Sorbian, but it breaks some latin-1 encoded texts due to their similarity, not all and not always (depending of the used characters).

If I understood, the encoding is not saved into the file, so C::B tries to guess the right one when the file is opened. So when you add the latin-2 encoding, some latin-1 files are seen as latin-2, so some characters are displayed in a wrong way.
So I change the option Settings >> Editor >> General Settings >> Use This Encoding to "As default encoding", so the C::B's auto-detectionis bypassed, and this solved my problem.

If this is the situation, I think that your idea of the configuration-option is the easiest one: I'm afraid that detecting latin-1 from latin-2 is not easy...

[Biplab]

If I understood, the encoding is not saved into the file, so C::B tries to guess the right one when the file is opened. So when you add the latin-2 encoding, some latin-1 files are seen as latin-2, so some characters are displayed in a wrong way.
So I change the option Settings >> Editor >> General Settings >> Use This Encoding to "As default encoding", so the C::B's auto-detectionis bypassed, and this solved my problem.

If this is the situation, I think that your idea of the configuration-option is the easiest one: I'm afraid that detecting latin-1 from latin-2 is not easy...

A file encoding is never saved to a file. At least I'm unaware of any widely popular method of storing file encoding data to a file. Reason is pretty simple. One need to strip that data (encoding detection data) before feeding it to another program. Or the other program should be aware of how to strip that data.

Most of the known software performs encoding detection by sampling data from file. There are BOM for UTF encoded file. But for other encoding sampling and measuring frequency of encoded characters is the only way to detect an encoding. Mozilla's encoding detection is an example of this.

For a large project with files encoded with a less popular encoding scheme will surely degrade Code:Blocks' performance. Precisely this was the reason Yiannis objected (long ago) to the inclusion of Mozilla's encoding detection code to trunk. IMHO it should be turned on as an Option only.

IMHO the solution should be to give user two option.
1) Use a simple encoding detection scheme (to detect most of the popular encodings).
2) Use Mozilla's code to detect encoding (we should make it very clear that this option may affect performance in some cases).
3) Don't detect encoding.

And to each of the above options Fallback Encoding options shall be-
a) Use System encoding.
b) Use User-provided encoding.

Code:Blocks is an IDE & IMO we should try not to transform it to a Text Editor or a Browser.