> C::B tries to be smart an goes to the first error, this is useful most of the time
IMHO, a GUI designer should be very careful about insisting on asynchronously yanking the keyboard focus. That policy might be appealing with nubees, but will be less popular with seasoned users. For example, it can be vexing for users that try to work in parallel with the build in C::B. The build can take longer on large projects. I'm certain that MSVC doesn't asynchronously yank the focus. I suspect you will find the same policy is implemented with other IDEs that have a large installed base.
> I hope you've set Settings -> Editor -> General -> Other settings -> Editor's name is file's to name only (no path information)!
Just now made this change, thanks.
> For the slow down, please use perf or other profiler and show the backtrace. I don't think I've seen it slow down.
This is ubuntu running as vmware guest nested in windows so graphics performance is maybe suboptimal. Nevertheless, I notice that restarting C::B seems to fix the issue. I will try to grab some traces when I have some time.
> I also hope you not using step, next of similar commands in the debugger's command line, it is not intended for this kind of commands and they'll
> mess the debugging pretty much.
I have definitely experienced this issue, it hangs up the GUI sometimes, and the only resolution is to kill C::B. Its easy to make this mistake if you are also a gdb command line user. I don't seem to recall experiencing this type of issues with other gdb debugger wrapper GUIs such as DDD, or the sun microsystems debugger. They must have arrived at a solution for tracking the internal state of the debugger in the gui, but unfortunately I cant make any suggestions. Its easier to whine than actually fix it DYN.