Distinguish error/warning in compilation-mode

[pnkfelix]

Use naive multiline regexp to match message type and file:line:col spec in one step.

Spawned off from #154 (comment)

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[nikomatsakis]

So, as I wrote on IRC, I tried this but had problems because we wound sometimes flush buffers (on the rustc side) at inconvenient times. However, rust-lang/rust#35975 seems to have fixed this behavior (at least on Mac/Unix), so I expect that multiline-regex will work now.

[pnkfelix]

Hmm now that I understand the problem that @nikomatsakis described, it is possible that I am actually observing it within my emacs instance (just not as frequently as he was, at least in rustc builds).

I will look into changing the code so that it uses the multiline regexp first and falls back on the one line one if necessary. (But I suspect I'll continue to leave out the scrolling...)

[pnkfelix]

cc #156

[pnkfelix]

cc #170

[nikomatsakis]

I will look into changing the code so that it uses the multiline regexp first and falls back on the one line one if necessary. (But I suspect I'll continue to leave out the scrolling...)

Hmm, without the scrolling it is pretty annoying to use the one line regex, at least if you follow my workflow of doing M-x next-error a lot.

[nikomatsakis]

@pnkfelix what's the story with your investigations into multi-line-regexp here?

Have you been using this patch locally? I guess that if we have the fallback, this is no worse than the existing scenario, but it seems odd to me that it will be inconsistent in its ability to detect warnings. Still...

[pnkfelix]

@nikomatsakis my experience is that using the multiline regexp hits a bug in compile.el, which I think you yourself had encountered? I filed it against emacs and they confirmed the bug, number 25133 : https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25133

Doesn't help us resolve this in short term of course; but the basic answer is that for now the multi line regexp is a no go

[nikomatsakis]

@pnkfelix maybe you can close this PR but file some notes in a suitable issue (do we have one already?)

good to know that they acknowledged it as a bug