I've never been a fan of tight compiler/editor integration. It either requires O(number of compilers × number of editors) work to set up, or it fails to give people an independent choice of compiler and editor. And in any case, I quite often find myself in silly situations involving running my editor on one machine and my compiler on another, at which point I tend to be glad I'm not committed to tightly coupling the two.

My proposal requires O(number of compilers + number of editors) work to set up, and copes transparently with arbitrarily silly compile arrangements. The only real point against it is that it's barking mad.

The relevant integration here is the editor being able to parse error messages to find the source file and line, something that's indispensable even if it doesn't perform cleverness regarding changes to the source file.

But there's at least an implicit requirement to have the compiler's error messages show up in the editor in the first place. Cutting and pasting the whole lot into a compiler-error-oriented editor buffer, and arranging to have the source file pathnames translated between the compiler's and editor's filesystem views (e.g. translating Windows to Unix path separators and prepending the right top-level source directory) would be significantly more inconvenient than just typing a three- or four-digit line number every time I want to move to the next error.

That's a trivial variant of getting the output of any other command into your editor - also something that's indispensable for other reasons.

there's at least an implicit requirement to have the compiler's error messages show up in the editor in the first place

In Emacs, you type M-x compile RET and then enter your command (typically make).

translating Windows to Unix path separators and prepending the right top-level source directory

Emacs does this automatically. And it can handle cygwin paths too using the cygwin-mount library.

(I don't want to sound like an Emacs zealot so I'll stop now...)

Of course M-x compile doesn't work quite so well when you're running your compile on one machine and the editor on another...

In that case, wouldn't you type something like M-x compile RET ssh user@host make RET? (Or whatever mechanism you use to run a command remotely.) You probably also need to organize some form of path translation in this case: that's what file-name-handler-alist is for.

The approved mechanism in this case is to run a command saying "I want an interactive session on a random machine, give me an xterm" and then do everything in that xterm or things spawned from it. sshing into the machines directly is frowned upon. I suppose one could do compiles as a batch job but that feels distressingly 1970s.

(I'm sure something is possible, it just needs more tuits than I've come up with so far.)

I'm currently contemplating the idea of running an appropriately configured sshd under my own uid as my primary interactive-session process, and sshing in to that from my desktop box. That way all my processes are still children of the process they ought to be, which means in particular that if CPU-time accounting is going on then it will still give the right answers, but I also get to use sensible X forwarding and so forth.

The sshd idea sounds neat but also sounds like it makes it even easier to accidentally leave interactive sessions running over the weekend ;-)