you have to mentally adjust all the line numbers in the subsequent error messages
Or you could use a development environment which handles this book-keeping for you. This need not involve any compiler/editor integration at all. For example, Emacs has a "compilation-mode" for reading the output of compilers; for each error message in the compiler's output it creates a marker (a kind of bookmark) for the original position of the error in the file. This marker stays with the text even if you add or delete lines above or below it, so you just run the command ‘next-error’ to go to the next error without needing to do any mental adjustment. I'm sure other programmer editors do something similar.
I do occasionally wonder about defecting to Emacs from my current choice of Jed (which is basically Emacs-like in its key bindings but completely different under the hood). At the time I made the choice, Jed had far better syntax highlighting and was considerably smaller and faster; these days Moore's Law has rendered the latter points largely irrelevant, Jed's syntax highlighting has got noticeably worse, and I imagine people have been hard at work improving Emacs's.
My primary reason not to is that I'd have to translate ten years' worth of accumulated editor configuration written in Jed's embedded scripting language, including my personal MUA...
You might want to have a look. Emacs went through a bit of a doldrums in the early 2000s as it took six years to bring out version 21 *. But now it seems back on track, and if you used to be a fan, but haven't used it since version 20 I think you may be pleasantly surprised with version 22.
* Native windowing system integration was pretty tough, but I think the big problem was Unicode. Emacs was a victim of being a first mover here: in the 1990s it had adopted its own system (MULE) for integration of multilingual character sets, so when Unicode turned out to be the standard way to achieve this, MULE had to be backed out while the rather complex interface remained backwards compatible to avoid breaking a vast installed codebase.
Yes, I do mean worse in absolute terms. What happened was, there were two separate highlighting mechanisms in Jed. One was a sort of ad-hoc thing hard-coded in the editor's C core, which was basically just about usable for highlighting C and could also be extended to other basically programming-language-shaped syntaxes by configuring it at the general level of "this is the comment character, this is the list of operators, these are delimiters etc". The other was based on regular expressions and was much more flexible and general, and in particular one could configure it entirely in the customisation language to be suitable for things that had nothing at all to do with programming languages. I had hoped that highlighting schemes based on the former would gradually migrate to the latter and then the former would be thrown away, but it appears that in fact the latter has fallen into disuse and more and more language modes are reverting to the (now somewhat souped up but still not really as flexible as it should be) former. I think part of the reason for this is that the maintainers didn't really understand the regexp-based scheme, so when it came to adding new features they tended to graft them on to the one they knew how to modify.
VS seems to track the changes very well. If you click on an error message, you nearly always get taken to the correct line, even after having made substantial changes elsewhere in the file. That way, the line numbers become quite irrelevant. VS only gets really confused if you actually delete the line that the error itself was on.
Or you could use a development environment which handles this book-keeping for you. This need not involve any compiler/editor integration at all. For example, Emacs has a "compilation-mode" for reading the output of compilers; for each error message in the compiler's output it creates a marker (a kind of bookmark) for the original position of the error in the file. This marker stays with the text even if you add or delete lines above or below it, so you just run the command ‘next-error’ to go to the next error without needing to do any mental adjustment. I'm sure other programmer editors do something similar.
My primary reason not to is that I'd have to translate ten years' worth of accumulated editor configuration written in Jed's embedded scripting language, including my personal MUA...
* Native windowing system integration was pretty tough, but I think the big problem was Unicode. Emacs was a victim of being a first mover here: in the 1990s it had adopted its own system (MULE) for integration of multilingual character sets, so when Unicode turned out to be the standard way to achieve this, MULE had to be backed out while the rather complex interface remained backwards compatible to avoid breaking a vast installed codebase.
That must have taken some special effort.
Do you really mean, worse in absolute? Or merely "not as good as what other programs offer these days"?
If the former, I wonder what made people take something that works and make it worse.
And yeah, it's very nice.
And if it starts to lose where the errors are then I just hit compile again - even with reasonably large systems it's only 30 seconds to do a build.