unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#58653: 29.0.50; Long lines in *compilation* buffer
@ 2022-10-20  9:05 Gerd Möllmann
  2022-11-03  6:11 ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-10-20  9:05 UTC (permalink / raw)
  To: 58653

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.









^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-10-20  9:05 bug#58653: 29.0.50; Long lines in *compilation* buffer Gerd Möllmann
@ 2022-11-03  6:11 ` Gerd Möllmann
  2022-11-03  8:18   ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03  6:11 UTC (permalink / raw)
  To: 58653

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03  6:11 ` Gerd Möllmann
@ 2022-11-03  8:18   ` Eli Zaretskii
  2022-11-03  8:43     ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-03  8:18 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 58653

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03  8:18   ` Eli Zaretskii
@ 2022-11-03  8:43     ` Gerd Möllmann
  2022-11-03  9:02       ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03  8:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03  8:43     ` Gerd Möllmann
@ 2022-11-03  9:02       ` Eli Zaretskii
  2022-11-03  9:10         ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-03  9:02 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 58653

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03  9:02       ` Eli Zaretskii
@ 2022-11-03  9:10         ` Gerd Möllmann
  2022-11-03 12:13           ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03  9:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03  9:10         ` Gerd Möllmann
@ 2022-11-03 12:13           ` Gerd Möllmann
  2022-11-03 12:43             ` Gerd Möllmann
  2022-11-03 13:34             ` Eli Zaretskii
  0 siblings, 2 replies; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03 12:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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







^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 12:13           ` Gerd Möllmann
@ 2022-11-03 12:43             ` Gerd Möllmann
  2022-11-03 13:34             ` Eli Zaretskii
  1 sibling, 0 replies; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03 12:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 12:13           ` Gerd Möllmann
  2022-11-03 12:43             ` Gerd Möllmann
@ 2022-11-03 13:34             ` Eli Zaretskii
  2022-11-03 13:39               ` Gerd Möllmann
  1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-03 13:34 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 58653

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 13:34             ` Eli Zaretskii
@ 2022-11-03 13:39               ` Gerd Möllmann
  2022-11-03 13:57                 ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03 13:39 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 13:39               ` Gerd Möllmann
@ 2022-11-03 13:57                 ` Gerd Möllmann
  2022-11-03 14:13                   ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03 13:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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!





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 13:57                 ` Gerd Möllmann
@ 2022-11-03 14:13                   ` Eli Zaretskii
  2022-11-03 14:15                     ` Gerd Möllmann
  0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-03 14:13 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 58653

> 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?





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 14:13                   ` Eli Zaretskii
@ 2022-11-03 14:15                     ` Gerd Möllmann
  2022-11-03 14:37                       ` Eli Zaretskii
  0 siblings, 1 reply; 14+ messages in thread
From: Gerd Möllmann @ 2022-11-03 14:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 58653

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

Yes, I've done that now.





^ permalink raw reply	[flat|nested] 14+ messages in thread

* bug#58653: 29.0.50; Long lines in *compilation* buffer
  2022-11-03 14:15                     ` Gerd Möllmann
@ 2022-11-03 14:37                       ` Eli Zaretskii
  0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2022-11-03 14:37 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 58653-done

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





^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-11-03 14:37 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-20  9:05 bug#58653: 29.0.50; Long lines in *compilation* buffer Gerd Möllmann
2022-11-03  6:11 ` Gerd Möllmann
2022-11-03  8:18   ` Eli Zaretskii
2022-11-03  8:43     ` Gerd Möllmann
2022-11-03  9:02       ` Eli Zaretskii
2022-11-03  9:10         ` Gerd Möllmann
2022-11-03 12:13           ` Gerd Möllmann
2022-11-03 12:43             ` Gerd Möllmann
2022-11-03 13:34             ` Eli Zaretskii
2022-11-03 13:39               ` Gerd Möllmann
2022-11-03 13:57                 ` Gerd Möllmann
2022-11-03 14:13                   ` Eli Zaretskii
2022-11-03 14:15                     ` Gerd Möllmann
2022-11-03 14:37                       ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).