Open Curly Brace doesn't work in Mac OS X 10.9

[eguerr]

Hi all,

I'm new to CodeBlocks and English is not my native language. I apologize if I am asking something already answered. I have searched with no result.

I'm running CodeBlocks v 13.12 for Mac OS X, and opened a .cpp file (i also tried with a new file). I can insert the closing curly brace , }, but the opening one, {, doesn't work.

My keyboard layout is Spanish, and I insert it with Alt+´.

I disabled Keyboard Shortcuts plugin as I have already read on the Internet, restarted CB, but no luck.

I have also seen that inserting @ (Alt+2) or # (Alt+3) works, so it's not a global problem with Alt+something. Same happens with [ and ]. I can insert the closing one (Alt++) but not the opening one (Alt+`).

I hope someone can help me, as it's impossible to code without opening braces. Thanks in advance

Enrique

[BlueHazzard]

have you tried this:
http://wiki.codeblocks.org/index.php?title=FAQ-Issues_and_Workarounds#Q:_I_cannot_type_a_greater-than_.27.3E.27_sign.3F

greetings

[eguerr]

Thank you, BlueHazzard, for your quick answer!

I have just tried it, with no luck. I get into Settings->Editor, but i can't find that "Keyboard Shortcuts" section. I get this screen. Where is the correct option? I'm sorry if it is so obvious.

[Jenna]

"Keyboard shortcuts" belongs to the keybinder-plugin, so you can not see it, if it is disabled.
If it does not crash C::B, you can try it.

[juanfal]

Our situation is even worse.  Here at the University of Málaga, we have a room full of Macs (our best room, of course) and although I'd rather teach using Terminal+Editor than using distractive IDEs, for many students using a graphical IDE seems to be more cool.  Anyway, the alternative, EclipseCpp is really bad, and we have been waiting for a version of CodeBlocks (the preferred for everybody else) that worked right with OSX.  It's amazing that such a bug:  not being able to read ⌥-´, that is behind the dead-key, '´', fails and does nothing!  instead as the rest of even Eclipse IDE:  {{{{{{{{  !!!!

Such a stupid bug is being there for every version I've tried for years.  I don't understand the people behind CodeBlocks.  Is it perhaps some way of punishment?  I don't understand

[Alpha]

I believe the largest reason why bugs like this have prolonged unfixed periods is that none of the active developers for C::B own a Mac system.  Without any actual access, attempting to resolve these bugs results in blind guessing.

[juanfal]

Is there any way to recompile CodeBlocks for OS X? Where are the sources (with patches, I suppose) for OS X?

[oBFusCATed]

Here: https://sourceforge.net/p/codeblocks/code/HEAD/tree/

Don't know it currently builds on osx.

[afb]

wxWidgets has problems with French and Spanish keyboard layouts (try by switching to a US layout)

The situation should be better in wxWidgets 3.0, and also there were some fixes/patches for wxScintilla

http://trac.wxwidgets.org/ticket/9663

[oBFusCATed]

Hm, then probably we should apply these in our version of wxscintilla, too.
Afb, can you try them?

[afb]

Hm, then probably we should apply these in our version of wxscintilla, too.
Afb, can you try them?

I could try the patch, but I don't have a Spanish (or French) keyboard - so I don't see the bug...
Supposedly* the situation is better with wxOSX 3.0.2, so I would like to see if it still remains first ?

* says http://trac.wxwidgets.org/ticket/15384

[afb]

I posted build instructions for OS X 10.9/10.10 (using homebrew) in the "Development" section:
http://forums.codeblocks.org/index.php/topic,20366.msg138642.html#msg138642

Unfortunately building wxMac 2.8.12 requires Mac OS X 10.6, it doesn't work on later OS versions.
So for using OS X 10.9, you would either have to use wxGTK 2.8.12 or wxOSX 3.0.2.

[juanfal]

Aster downloaded latest 10350-trunk version, I've tried to compile it, this is what I get, after 10 min compilation:

  https://asciinema.org/a/23016

[Jenna]

Aster downloaded latest 10350-trunk version, I've tried to compile it, this is what I get, after 10 min compilation:

  https://asciinema.org/a/23016

Can you please copy and paste the relevant part of the log.
Posting a link to a video with shell-output is not really useful.

[juanfal]

Yes, but the only thing I recognize here is the final error, the rest are the many warnings, such many that scares me.

You have this last part here, the previous part is all warnings.  In fact you can copy the text of these asciinema "movies":

  https://gist.github.com/6d2baa88e31ea9f0a0c1.git

[afb]

Thinking that it has something to do with the precompiled headers. Try configure with --disable-pch.

(https://gist.github.com/juanfal/6d2baa88e31ea9f0a0c1)

Code

In file included from ../../../src/include/sdk.h:17:
In file included from ../../../src/include/sdk_precomp.h:13:
In file included from ../../../src/include/sdk_common.h:43:
../../../src/include/prep.h:33:75: error: use of overloaded operator '==' is ambiguous (with operand types 'const std::__1::shared_ptr<GDBWatch>' and
      'int')
        template<typename T> bool equals(T const& rhs) const { return rhs == 0; }
                                                                      ~~~ ^  ~

You might also want to configure with --enable-std_string when compiling wxWidgets with clang++.


See also http://sourceforge.net/p/codeblocks/tickets/13/
(it contains some more details, from the macports port)

[oBFusCATed]

What happens if you try this patch?

Code: diff

diff --git a/src/include/prep.h b/src/include/prep.h
index 7e114a0..81fbf86 100644
--- a/src/include/prep.h
+++ b/src/include/prep.h
@@ -17,8 +17,17 @@
     #define __has_feature(x) 0
 #endif
 
-#if    !(((__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4) && defined __GXX_EXPERIMENTAL_CXX0X__) \
-    && !(defined(__clang__) && __has_feature(cxx_nullptr))
+#if __cplusplus>=201103L
+    #define CB_HAS_NULLPTR 1
+#elif ((__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4) && defined __GXX_EXPERIMENTAL_CXX0X__
+    #define CB_HAS_NULLPTR 1
+#elif defined(__clang__) && __has_feature(cxx_nullptr)
+    #define CB_HAS_NULLPTR 1
+#else
+    #define CB_HAS_NULLPTR 0
+#endif
+
+#if CB_HAS_NULLPTR!=1diff --git a/src/include/prep.h b/src/include/prep.h
index 7e114a0..81fbf86 100644
--- a/src/include/prep.h
+++ b/src/include/prep.h
@@ -17,8 +17,17 @@
     #define __has_feature(x) 0
 #endif
 
-#if    !(((__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4) && defined __GXX_EXPERIMENTAL_CXX0X__) \
-    && !(defined(__clang__) && __has_feature(cxx_nullptr))
+#if __cplusplus>=201103L
+    #define CB_HAS_NULLPTR 1
+#elif ((__GNUC__ == 4 && __GNUC_MINOR__ >= 6) || __GNUC__ > 4) && defined __GXX_EXPERIMENTAL_CXX0X__
+    #define CB_HAS_NULLPTR 1
+#elif defined(__clang__) && __has_feature(cxx_nullptr)
+    #define CB_HAS_NULLPTR 1
+#else
+    #define CB_HAS_NULLPTR 0
+#endif
+
+#if CB_HAS_NULLPTR!=1
     // it is a const object...
     const class nullptr_t
     {

     // it is a const object...
     const class nullptr_t
     {

Also what c++ stdlib are you using - libc++ or libstdc++?
The former is the only way to get c++11 features on osx as far as I know and also it is always building in c++11 mode.

Mixing the two is probably bad idea. Also I think people building on OSX should try to use libc++, c++11 and wxCocoa-3.x.
Trying to use the old wx is a waste of time in my opinion.

And lastly cb core seems to build fine with gcc-4.8.5, -std=c++11 and no -ansi flag (passing -ansi and -std=c++11, causes lots of problems).

[oBFusCATed]

Has anyone tried my patch?

[Stashue]

So what is the final solution to the problem with the braces?  I didn't understand

[oBFusCATed]

Have you tried the latest night build? See the night build subforum. There are new builds.