bug#13594: 24.2.92; [PATCH] compilation-start doesn't consider nil OUTWIN

[Leo Liu]

On 2013-02-06 07:25 +0800, Juri Linkov wrote:
> Some users of `async-shell-command' want the same feature of
> not displaying the output buffer.  From the old discussion
> I got the impression that such customization should be possible
> by customizing `display-buffer-alist' and associating
> the buffer name (such as *compilation* or *Async Shell Command*)
> with an inaction to skip window display.

Would be nice to see how to do it using display-buffer-alist. From my
understanding and as Stefan suggested, the best thing to do is not to
call display buffer if the intention is not to display it.

>> 2. Display a message when calling compilation-next-error like this:
>>    Error: 2/623
>
> I think it would be nice to display the same in the mode line.

Yes I agree but let's get the count of errors right first.

>> Sadly this second patch doesn't account for the fact that some
>> compilation messages are removed later on by font-lock.
>
> `grep' used to remove parts of grep/compilation messages,
> but now there shouldn't be such a problem in grep's font-lock.
> Do you have a test case that would demonstrate this problem
> in compilation's font-lock?

I mean the 'compilation-message' property. In my second patch, the count
is based on each compilation-message properties inserted but it is
removed in, for example, these lines:

        Grep started at Wed Feb  6 09:11:06
        Grep finished (matches found) at Wed Feb  6 09:11:06

Here is the latest patches in one diff:
http://bpaste.net/show/npDaKs5Wvuk2AxSWgOiV

The total error count is still incorrect because (compilation-next-error
-1 nil (point-max)) doesn't find me the last real error but:

        Grep finished (matches found) at Wed Feb  6 09:11:06

bug13594.png
Description: bug13594.png

Leo