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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42806 in the body.
You can then email your comments to 42806 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH 0/1] Parse whole buffer of compilation output at once
Date: Mon, 10 Aug 2020 23:27:56 +0200

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.

`rustc' was one compiler that was often affected by this.  I am sure
there are others.

     Cheers,
     Jonas

Jonas Bernoulli (1):
  Parse whole buffer of compilation output at once

 lisp/progmodes/compile.el | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

-- 
2.28.0

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

From: Jonas Bernoulli <jonas <at> bernoul.li>
To: 42806 <at> debbugs.gnu.org
Subject: [PATCH 1/1] Parse whole buffer of compilation output at once
Date: Mon, 10 Aug 2020 23:30:59 +0200

* 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.
---
 lisp/progmodes/compile.el | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 0b9f417845..5b171fe966 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2417,12 +2417,9 @@ compilation-next-single-property-change
                                                 &optional object limit)
   (let (parsed res)
     (while (progn
-             ;; We parse the buffer here "on-demand" by chunks of 500 chars.
-             ;; But we could also just parse the whole buffer.
              (compilation--ensure-parse
               (setq parsed (max compilation--parsed
-                                (min (+ position 500)
-                                     (or limit (point-max))))))
+                                (or limit (point-max)))))
              (and (or (not (setq res (next-single-property-change
                                       position prop object limit)))
                       (eq res limit))
-- 
2.28.0

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 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 16:19:08 +0200

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.  :-)

So I've applied this to Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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.

Previous Next

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