bug#42806: [PATCH 0/1] Parse whole buffer of compilation output at once

bug#42806: [PATCH 0/1] Parse whole buffer of compilation output at once

[Jonas Bernoulli]

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

bug#42806: [PATCH 1/1] Parse whole buffer of compilation output at once

[Jonas Bernoulli]

* 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

bug#42806: [PATCH 1/1] Parse whole buffer of compilation output at once

[Lars Ingebrigtsen]

Jonas Bernoulli <jonas@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

bug#42806: [PATCH 1/1] Parse whole buffer of compilation output at once

[Noam Postavsky]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Jonas Bernoulli <jonas@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.