help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: encoding in *compilation-buffer*


From: Alain Ketterlin
Subject: Re: encoding in *compilation-buffer*
Date: Sat, 19 Feb 2011 18:12:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Peter Dyballa <Peter_Dyballa@Web.DE> writes:

> Am 19.02.2011 um 16:03 schrieb Alain Ketterlin:
>
>> I've missed the start of the thread, but isn't
>> ansi-color-for-comint-mode supposed to solve this?
>
> As the function's name tell: It seems to be meant for comint-mode.
> This does not seem to exist in *compilation* buffers.

Sorry, I was somehow assuming that the *compilation* buffer was in
comint mode. Actually, setting ansi-color-for-comint-mode to t and
invoking:

    C-u M-x compile RET ls -l --color=always RET

uses comint and produces ansi-color-ful output. Omitting the prefix arg
shows ugly ansi sequences and no color.

> Could /you/ make a test with this "colorgcc" wrapper? On my Mac OS X
> system it does not exist. By temporarily commenting ansi-color-for- 
> comint-mode in your init file and launching a second GNU Emacs you
> should be able to notice a difference...

I don't use colorgcc or any kind of wrapper. I have colorful messages in
the compilation buffer thanks to compilation-mode's own output parsing
and font-lock settings.

More precisely: if I launch a regular compile with

    M-x compile RET gcc whatever.c

I get no ansi sequences in the output. That's why I said that gcc is not
responsible for the sequences.

The OP's "javatolatex" (iirc) probably pipes gcc's output through a
wrapper. Either he changes his script to not produces the ansi
sequences, or he switches to comint-based compilation and sets
ansi-color-for-comint-mode. Once this variable is set, he can also use
either M-x shell, or M-x term.

-- Alain.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]