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