GNU bug report logs - #58653
29.0.50; Long lines in *compilation* buffer

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 58653 in the body.
You can then email your comments to 58653 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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 20 Oct 2022 11:05:41 +0200

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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 07:11:18 +0100

Gerd Möllmann <gerd.moellmann <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 10:18:37 +0200

> From: Gerd Möllmann <gerd.moellmann <at> 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 09:43:39 +0100

Eli Zaretskii <eliz <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 11:02:14 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 58653 <at> debbugs.gnu.org
> Date: Thu, 03 Nov 2022 09:43:39 +0100
> 
> Eli Zaretskii <eliz <at> 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 3 Nov 2022 10:10:19 +0100

On 03.11.22 10:02, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann <at> 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 :-).

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 13:13:22 +0100

Gerd Möllmann <gerd.moellmann <at> 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 :-/.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 13:43:26 +0100

Gerd Möllmann <gerd.moellmann <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 15:34:15 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 58653 <at> 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 3 Nov 2022 14:39:15 +0100

On 03.11.22 14:34, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Cc: 58653 <at> 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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 14:57:22 +0100

Gerd Möllmann <gerd.moellmann <at> 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!

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 16:13:25 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: 58653 <at> debbugs.gnu.org
> Date: Thu, 03 Nov 2022 14:57:22 +0100
> 
> Gerd Möllmann <gerd.moellmann <at> 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?

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58653 <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 3 Nov 2022 15:15:05 +0100

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

Yes, I've done that now.

Message #46 received at 58653-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 58653-done <at> debbugs.gnu.org
Subject: Re: bug#58653: 29.0.50; Long lines in *compilation* buffer
Date: Thu, 03 Nov 2022 16:37:09 +0200

> Date: Thu, 3 Nov 2022 15:15:05 +0100
> Cc: 58653 <at> debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann <at> 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.

Previous Next

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