Bug 12 - Emacs Compile + colorgcc don\'t work well
Summary: Emacs Compile + colorgcc don\'t work well
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: emacs-common (show other bugs)
Version: unstable
Hardware: all Linux
: P4 minor
Assignee: Ivan Zakharyaschev
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-09-29 17:42 MSD by Peter 'Nidd' Novodvorsky
Modified: 2003-08-25 15:18 MSD (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter 'Nidd' Novodvorsky 2001-09-29 17:42:22 MSD
Compile function (called by menu item Tools->Compile) doesn\'t
care about TERM environment variable, so the compiler process gets it
inherited from the Emacs process (and, for example, if Emacs is called
from an Xterm, then TERM=xterm for the compiler process). But actually
the  output of the compiler process goes to Emacs buffer through a
virtual terminal, and TERM doesn\'t correspond to the type of the
actual terminal. As a consequence, some junk (escape sequences) may
appear in the buffer. Moreover, the output is parsed by Emacs, and
because of the escape-sequences in it the parsing fails.

This bad thing about the Compile function can be observed when you
have colorgcc installed in your system (and when it is chosen by
update-alternatives).
---
 Make sure colorgcc is used when you call gcc. Then start Emacs
from an Xterm (where TERM=xterm) and open a C-source file (foo.c) from a
directory with a Makefile (so that foo.c is compiled with gcc when you
call make). Make an error in foo.c. Go to the menu Tools and run
Compile. `make -k\' will be executed. In the buffer `*compilation\' you
will see some junk and the output will not be highlighted
correctly. You won\'t be able to use Next error function.

To see that the there is a problem with TERM, you can add a statement like `echo
 
---
I suggest a fix that sets TERM=dumb in the environment of the compiler
process when calling it. I am not sure whether such solution is good
enough. 

The patch can be found in basalt:/raid/imz/OUT/READY/emacs/

Comment 1 Peter 'Nidd' Novodvorsky 2001-09-30 12:39:26 MSD
Isn\'t closed
Comment 2 Peter 'Nidd' Novodvorsky 2001-09-30 12:39:26 MSD
Isn\'t closed
Comment 3 Peter 'Nidd' Novodvorsky 2001-09-30 12:40:43 MSD
Closed in 20.7-alt1. Package is in incoming.
Comment 4 Peter 'Nidd' Novodvorsky 2001-09-30 12:40:43 MSD
Closed in 20.7-alt1. Package is in incoming.
Comment 5 imz 2001-10-03 20:34:58 MSD
I can\'t find the new package where this is fixed. (About the release numbre: is it OK to call it \'alt1\' after \'ipl9mdk\': rpm will think alt1 is older.)
Comment 6 imz 2001-10-03 20:34:58 MSD
I can\'t find the new package where this is fixed. (About the release numbre: is it OK to call it \'alt1\' after \'ipl9mdk\': rpm will think alt1 is older.)
Comment 7 imz 2001-12-26 18:56:02 MSK
The patch is applied in emacs-21.1-alt6, that is being built right now.
If it works, will close the bug.
Comment 8 imz 2001-12-26 18:56:02 MSK
The patch is applied in emacs-21.1-alt6, that is being built right now.
If it works, will close the bug.
Comment 9 imz 2002-01-01 22:45:02 MSK
 Really fixed only in emacs-common-21.1-alt8. Patch supplied to gnu.org.
Comment 10 imz 2002-01-01 22:45:02 MSK
 Really fixed only in emacs-common-21.1-alt8. Patch supplied to gnu.org.