Actually the problem has more implications, as it's an effect of parsing the code. Any IDE:s that have advanced features that rely on parsing and analysis of the code can be caught in an infinite loop and stop responding.
The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undecidability.
In theory, yes. Of course in practice, it's not so bad: they can run the parser in a different thread, they can put hard limits on how long they run, etc.
(The hard limit is how C++ gets parsed, I think. Since parsing C++ is also undecidable thanks to weird interactions with template metaprogramming.)
For simpler languages you can implement logic in the editor / IDE for things like precise autocomplete and parsing.
For C++ even precise syntax colouring would be undecidable---and just hard to get the logic right. There are two ways out: (1) implement an approximation and the occasional impression, (2) ask the compiler for help. I think the llvm project helps with the latter.
(What does emacs have to do with things? Or do you mean you are using emacs without any special support for C++? With the right modes you can turn your emacs (or vim etc) into basically a fully fledged IDE.)
The sad part is, in the general case it's impossible for the parser (or any other process overviewing it) to decide if it's actually caught in an infinite loop or not, that's why they call it undecidability.