GNU bug report logs - #68724
eshell/make doesn't properly handle color term characters

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 68724 in the body.
You can then email your comments to 68724 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: Patrick Poitras <patrick.f.poitras <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: eshell/make doesn't properly handle color term characters
Date: Thu, 25 Jan 2024 16:54:45 -0800

[Message part 1 (text/plain, inline)]

In eshell, if I am in a directory and call `make`, the call that is
executed is (eshell/make) from em-unix.el.

The *compilation* window then pops up, which reads:
-------
make
g++ main.cpp -o main -lsfml-graphics -lsfml-window -lsfml-system
[01m [Kmain.cpp: [m [K In function ‘ [01m [Kint [01;32m [K main [m [K() [m
[K’:
[01m [Kmain.cpp:41:21: [m [K [01;31m [Kerror: [m [Ktoo few arguments to
function ‘ [01m [Kvoid [01;32m [K handleCamera [m [K(sf::View&, const
sf::Time&) [m [K’
   41 |         [01;31m [KhandleCamera(view) [m [K;
      |         [01;31m [K~~~~~~~~~~~~^~~~~~ [m [K
[01m [Kmain.cpp:7:6: [m [K [01;36m [Knote: [m [Kdeclared here
    7 | void [01;36m [KhandleCamera [m [K(sf::View &view, const sf::Time
&time) {
      |       [01;36m [K^~~~~~~~~~~~ [m [K
make: *** [Makefile:2: game] Error 1

Compilation exited abnormally with code 2 at Thu Jan 25 16:47:18, duration
0.28 s
------

Note that the garbled text above is not a problem with me copy-pasting it .
The screen I see really writes out these `[01;31m` characters all over,
making the message comprehensible.

I thought this might be a locale issue, so I called make like this:
------
~/Projects/SFML $ LC_LANG=en_US.utf8 make
-------
Which doesn't pop-up the *compilations* buffer, but does print the correct
output:
--------
g++ main.cpp -o main -lsfml-graphics -lsfml-window -lsfml-system
main.cpp: In function ‘int main()’:
main.cpp:41:21: error: too few arguments to function ‘void
handleCamera(sf::View&, const sf::Time&)’
   41 |         handleCamera(view);
      |         ~~~~~~~~~~~~^~~~~~
main.cpp:7:6: note: declared here
    7 | void handleCamera(sf::View &view, const sf::Time &time) {
      |      ^~~~~~~~~~~~
make: *** [Makefile:2: game] Error 1
------
Which is properly colored and everything.

I also figured out that the LC_LANG isn't special it's just bypassing the
call to the native function, in fact, you get the same result if you call
-------
ASDASDFASD=ASDFASDF make
-------

Is this a known behavior with a workaround, or how do I troubleshoot this
further.

Thanks,
Patrick

[Message part 2 (text/html, inline)]

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Patrick Poitras <patrick.f.poitras <at> gmail.com>, 68724-done <at> debbugs.gnu.org
Subject: Re: bug#68724: eshell/make doesn't properly handle color term
 characters
Date: Thu, 25 Jan 2024 17:18:23 -0800

On 1/25/2024 4:54 PM, Patrick Poitras wrote:
> In eshell, if I am in a directory and call `make`, the call that is 
> executed is (eshell/make) from em-unix.el.
> 
> The *compilation* window then pops up, which reads: ...

Thanks for the bug report. I'm guessing you're using Emacs 30.0.50. This 
is a bug, in that eshell/make should print its output to the Eshell 
buffer by default (not a new compilation buffer). That's now fixed in 
4834be0949e on master, so closing this issue.

However, for fixing the colors in the compilation buffer, you can also 
add 'ansi-color-compilation-filter' to 'compilation-filter-hook'.

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

From: Patrick Poitras <patrick.f.poitras <at> gmail.com>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 68724-done <at> debbugs.gnu.org
Subject: Re: bug#68724: eshell/make doesn't properly handle color term
 characters
Date: Thu, 25 Jan 2024 17:31:07 -0800

[Message part 1 (text/plain, inline)]

This is what happens when I file bug reports while sick. Forgot a bunch of
details. My apologies.

Yeah, bug reported from emacs 30.0.50 @ 4e260bfc47e on master. Can confirm
that it's now fix on latest master.

Thanks!

On Thu, Jan 25, 2024 at 5:18 PM Jim Porter <jporterbugs <at> gmail.com> wrote:

> On 1/25/2024 4:54 PM, Patrick Poitras wrote:
> > In eshell, if I am in a directory and call `make`, the call that is
> > executed is (eshell/make) from em-unix.el.
> >
> > The *compilation* window then pops up, which reads: ...
>
> Thanks for the bug report. I'm guessing you're using Emacs 30.0.50. This
> is a bug, in that eshell/make should print its output to the Eshell
> buffer by default (not a new compilation buffer). That's now fixed in
> 4834be0949e on master, so closing this issue.
>
> However, for fixing the colors in the compilation buffer, you can also
> add 'ansi-color-compilation-filter' to 'compilation-filter-hook'.
>

[Message part 2 (text/html, inline)]

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Patrick Poitras <patrick.f.poitras <at> gmail.com>
Cc: 68724 <at> debbugs.gnu.org
Subject: Re: bug#68724: eshell/make doesn't properly handle color term
 characters
Date: Thu, 25 Jan 2024 17:59:27 -0800

On 1/25/2024 5:31 PM, Patrick Poitras wrote:
> This is what happens when I file bug reports while sick. Forgot a bunch 
> of details. My apologies.

No worries! The second part of your message (about "VAR=value make" 
being a workaround) also made me look again at how Eshell handles local 
variable settings like that, which let me fix a longstanding bug in the 
code: "VAR=value cd dir/" didn't actually change the directory. That's 
now fixed as well on master.

> Yeah, bug reported from emacs 30.0.50 @ 4e260bfc47e on master. Can 
> confirm that it's now fix on latest master.

Thanks for confirming the fix.

Previous Next

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