bug#58653: 29.0.50; Long lines in *compilation* buffer

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-09-21 built on
 Mini.fritz.box
Repository revision: 1231a601ebe1fd9fe454c504dbeb9267440242e7
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
 'configure --cache-file /Users/gerd/tmp/config.cache.master
 --with-native-compilation'

I did not find an easer way to reproduce this, sorry for that.

Configure Emacs with:

  ./configure --disable-silent-rules

so that compilation commands are shown in full.

Introduce something producing a warning or error in the C code, for
example in lisp.h.

Then do a full parallel build of Emacs (-j8 here).  This produces, on my
system, lines invoking gcc which are ca. 2000 chars wide.  These lines
are by default displayed with a [...].

Bug:

The errors or warnings appear sometimes truncated. For example, the file
name of the error message is not displayed.  Clicking on the [...]  does
not change that.  (And with the truncated messages, next-error cannot
work, ...)

I have no idea what that might be, so I'm just mentioning anything that
might be relevant, such as the parallel build.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.6.0, NS
>  appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-09-21 built on
>  Mini.fritz.box
> Repository revision: 1231a601ebe1fd9fe454c504dbeb9267440242e7
> Repository branch: master
> Windowing system distributor 'Apple', version 10.3.2113
> System Description:  macOS 12.6
>
> Configured using:
>  'configure --cache-file /Users/gerd/tmp/config.cache.master
>  --with-native-compilation'
>
> I did not find an easer way to reproduce this, sorry for that.
>
> Configure Emacs with:
>
>   ./configure --disable-silent-rules
>
> so that compilation commands are shown in full.
>
> Introduce something producing a warning or error in the C code, for
> example in lisp.h.
>
> Then do a full parallel build of Emacs (-j8 here).  This produces, on my
> system, lines invoking gcc which are ca. 2000 chars wide.  These lines
> are by default displayed with a [...].
>
> Bug:
>
> The errors or warnings appear sometimes truncated. For example, the file
> name of the error message is not displayed.  Clicking on the [...]  does
> not change that.  (And with the truncated messages, next-error cannot
> work, ...)
>
> I have no idea what that might be, so I'm just mentioning anything that
> might be relevant, such as the parallel build.

I'm meanwhile pretty sure that this does not happen when I invoke make
with -j1.

Another observation: I have truncate-lines nil in *compilation*.  The
continuation lines for the long gcc commands are displayed correctly
with these "curly" arrows.  The lines showing errors or warnings that
are chopped somehow display a triangle on the left margin, as if the
line were scolled.  I can't make sense of that at all.

Toggling truncate-lines, BTW, doesn't restore the missing text
(filenames for example).  

If someone has an idea where I could look for this in the code, please
let me know.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 03 Nov 2022 07:11:18 +0100
> 
> Another observation: I have truncate-lines nil in *compilation*.  The
> continuation lines for the long gcc commands are displayed correctly
> with these "curly" arrows.  The lines showing errors or warnings that
> are chopped somehow display a triangle on the left margin, as if the
> line were scolled.  I can't make sense of that at all.

That "triangle" is likely the "overlay-arrow" as it is displayed on
GUI frames.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> That "triangle" is likely the "overlay-arrow" as it is displayed on
> GUI frames.

Yes, indeed (slapping my head).

BTW, I've now checked that the missing text is really not in the buffer,
so it's not a display problem of some sort.

How strange.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 58653@debbugs.gnu.org
> Date: Thu, 03 Nov 2022 09:43:39 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That "triangle" is likely the "overlay-arrow" as it is displayed on
> > GUI frames.
> 
> Yes, indeed (slapping my head).
> 
> BTW, I've now checked that the missing text is really not in the buffer,
> so it's not a display problem of some sort.

I'm not surprised ;-)

> How strange.

Two possible suspects:

  . "M-x compile", which does something to truncate the long lines
  . the compiler itself: perhaps Emacs tells it the dimensions of the
    window, and the compiler adapts its output accordingly

Have fun.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

On 03.11.22 10:02, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> BTW, I've now checked that the missing text is really not in the buffer,
>> so it's not a display problem of some sort.
> 
> I'm not surprised ;-)

;-)

>> How strange.
> 
> Two possible suspects:
> 
>    . "M-x compile", which does something to truncate the long lines
>    . the compiler itself: perhaps Emacs tells it the dimensions of the
>      window, and the compiler adapts its output accordingly

Ok, thanks.

> 
> Have fun.

Hehe :-).

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> Have fun.
>
> Hehe :-).

I had some fun, and it gets even a bit weirder: The missing text doesn't
seem to be lost at all, it's just somewhere else.  Example:

  :22: warning: 'sprintf' is deprecated: ...

This should actually be xdisp.c:22:...

The xdisp.c can be found above that warning as part of a long line

  ebrew/Cellar/libidn2/2.3.4/include -isystem
  /opt/homebrew/Cellarxdisp.cAWK=awk ./mapconv glibc/IBM857.gz '/^<.*[
                      ^^^^^^^                   

And the newline before "AWK=" is probably also somewhere else.

That's a start :-/.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> I had some fun, and it gets even a bit weirder: The missing text doesn't
> seem to be lost at all, it's just somewhere else.  Example:
>
>   :22: warning: 'sprintf' is deprecated: ...
>
> This should actually be xdisp.c:22:...
>
> The xdisp.c can be found above that warning as part of a long line
>
>   ebrew/Cellar/libidn2/2.3.4/include -isystem
>   /opt/homebrew/Cellarxdisp.cAWK=awk ./mapconv glibc/IBM857.gz '/^<.*[
>                       ^^^^^^^                   
>
> And the newline before "AWK=" is probably also somewhere else.
>
> That's a start :-/.

Exactly the same happens when building in M-x shell.  And it doesn't
happen in a Terminal window.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 58653@debbugs.gnu.org
> Date: Thu, 03 Nov 2022 13:13:22 +0100
> 
>   :22: warning: 'sprintf' is deprecated: ...
> 
> This should actually be xdisp.c:22:...
> 
> The xdisp.c can be found above that warning as part of a long line
> 
>   ebrew/Cellar/libidn2/2.3.4/include -isystem
>   /opt/homebrew/Cellarxdisp.cAWK=awk ./mapconv glibc/IBM857.gz '/^<.*[
>                       ^^^^^^^                   
> 
> And the newline before "AWK=" is probably also somewhere else.

Are you building with -jN, i.e. in parallel?  Then what you see could
be the consequence of several processes writing simultaneously to the
same device.  If you use GNU Make, try adding the --output-sync=line
switch to the Make's command line.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

On 03.11.22 14:34, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: 58653@debbugs.gnu.org
>> Date: Thu, 03 Nov 2022 13:13:22 +0100
>>
>>    :22: warning: 'sprintf' is deprecated: ...
>>
>> This should actually be xdisp.c:22:...
>>
>> The xdisp.c can be found above that warning as part of a long line
>>
>>    ebrew/Cellar/libidn2/2.3.4/include -isystem
>>    /opt/homebrew/Cellarxdisp.cAWK=awk ./mapconv glibc/IBM857.gz '/^<.*[
>>                        ^^^^^^^
>>
>> And the newline before "AWK=" is probably also somewhere else.
> 
> Are you building with -jN, i.e. in parallel?  Then what you see could
> be the consequence of several processes writing simultaneously to the
> same device.  If you use GNU Make, try adding the --output-sync=line
> switch to the Make's command line.

Yes, I am building with GNU make 3.81, -j8 by default, which doesn't
seem to recognize --output-sync.

I'll try to get a newer gmake, and report back.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> Are you building with -jN, i.e. in parallel?  Then what you see could
>> be the consequence of several processes writing simultaneously to the
>> same device.  If you use GNU Make, try adding the --output-sync=line
>> switch to the Make's command line.
>
> Yes, I am building with GNU make 3.81, -j8 by default, which doesn't
> seem to recognize --output-sync.
>
> I'll try to get a newer gmake, and report back.

Yay, it works with GNU make 4.4!  And I was already digging in
process.c...

Thank you very much!

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: 58653@debbugs.gnu.org
> Date: Thu, 03 Nov 2022 14:57:22 +0100
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> >> Are you building with -jN, i.e. in parallel?  Then what you see could
> >> be the consequence of several processes writing simultaneously to the
> >> same device.  If you use GNU Make, try adding the --output-sync=line
> >> switch to the Make's command line.
> >
> > Yes, I am building with GNU make 3.81, -j8 by default, which doesn't
> > seem to recognize --output-sync.
> >
> > I'll try to get a newer gmake, and report back.
> 
> Yay, it works with GNU make 4.4!  And I was already digging in
> process.c...

Great, so can we close this bug?

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Gerd Möllmann]

On 03.11.22 15:13, Eli Zaretskii wrote:
> Great, so can we close this bug?

Yes, I've done that now.

bug#58653: 29.0.50; Long lines in *compilation* buffer

[Eli Zaretskii]

> Date: Thu, 3 Nov 2022 15:15:05 +0100
> Cc: 58653@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 
> On 03.11.22 15:13, Eli Zaretskii wrote:
> > Great, so can we close this bug?
> 
> Yes, I've done that now.

Doesn't look like it, but this message will.