GNU bug report logs - #42806
[PATCH 0/1] Parse whole buffer of compilation output at once

Previous Next

Package: emacs;

Reported by: Jonas Bernoulli <jonas <at> bernoul.li>

Date: Mon, 10 Aug 2020 21:29:02 UTC

Severity: normal

Tags: fixed, patch

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #18 received at 42806 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 42806 <at> debbugs.gnu.org
Subject: Re: bug#42806: [PATCH 1/1] Parse whole buffer of compilation output
 at once
Date: Fri, 14 Aug 2020 10:56:19 -0400
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Jonas Bernoulli <jonas <at> bernoul.li> writes:
>
>> * lisp/progmodes/compile.el (compilation-next-single-property-change):
>> Parse whole buffer at once.
>>
>> Remove the comment that mentioned that it is an option to do it in one
>> go as we now actually start doing.  As the existence of that comment
>> suggested, there is not really a reason to process the buffer in small
>> chunks.  On the contrary, processing the output in arbitrary units can
>> result in certain constructs not being recognized because they begin
>> in one arbitrary chunk, while ending in another.
>
> Makes sense to me, but I wonder what the reason for this
> 500-chars-at-a-time parsing was in the first place.
>
> I guess we'll find out if it breaks something, and should be ready to
> revert.  :-)

I suspect it would be to avoid long pauses if there is a lot of output
from the subprocess at once.




This bug report was last modified 4 years and 285 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.