encoding in *compilation-buffer*

encoding in *compilation-buffer*

[tlanglois]

Hello,
I am using :
GNU Emacs 22.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-03-31 on
crested, modified by Ubuntu

I use it a lot remotely with a xterm. 
In compilation buffers it seems that non 8bit characters are used which
truns error messages very hard to read :
javatolatex.lex:93: error: expected �[39;49m\200\230;�[39;49m\200\231 before
�[39;49m\200\230}�[39;49m\200\231 token

Is there a way to fix this ?

Thanks.


-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30934972.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 15.02.2011 um 23:03 schrieb tlanglois:

> Is there a way to fix this ?

Use xterm in UTF-8 mode (maybe uxterm) and set environment variables  
LC_CTYPE (and LANG too) to some UTF-8 based value (for example  
de_DE.UTF-8).

--
Greetings

   Pete

Hard Disk, n.:
	A device that allows users to delete vast quantities of data with  
simple mnemonic commands.

Re: encoding in *compilation-buffer*

[tlanglois]

Peter Dyballa wrote:
> 
> 
> Am 15.02.2011 um 23:03 schrieb tlanglois:
> 
>> Is there a way to fix this ?
> 
> Use xterm in UTF-8 mode (maybe uxterm) and set environment variables  
> LC_CTYPE (and LANG too) to some UTF-8 based value (for example  
> de_DE.UTF-8).
> 

Thanks for responding.

I've done what you suggest. In a uxterm I have :
$ locale
LANG=en_US.utf8
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=

but I get the same weird output in emacs.
If I issue the compilation command in a uxterm (o xterm with same locale
settings) the message is normal :
$ make -f make-javatolatex
gcc javatolatex.c -o javatolatex -lfl
javatolatex.lex:11: error: expected ‘,’ or ‘;’ before ‘void’
make: *** [javatolatex] Error 1

So it seems to be an emacs-related problem and not a problem related to the
terminal.

T.
-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30949803.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 17.02.2011 um 14:55 schrieb tlanglois:

> javatolatex.lex:11: error: expected ‘,’ or ‘;’ before ‘void’


Here you see the "typographic" quotes I recognised, but Stefan did not  
overlook your second problem! ANSI Esc sequences are sent to make the  
output look colourful. I haven't seen this. There are two options, I  
can think of: set TERM to a reasonable value, maybe xterm-256color, in  
case it's true (or smaller no. of colours or just xterm-color), and  
enable inside GNU Emacs handling of these codes with:

	(ansi-color-for-comint-mode-on)

This works, starting from *some* GNU Emacs 22.x, in shells. I'm not  
sure whether it works in a *compilation* buffer. And I'n not sure if  
it works when GNU Emacs runs without windows, i.e., when it depends on  
what this terminal emulation can perform.

Which tool is actually emitting these codes? (I presume it's this  
"javatolatex".) Does its documentation tell a bit about colours?


--
Greetings

   Pete

The mathematician who pursues his studies without clear views of this  
matter, must often have the uncomfortable feeling that his paper and  
pencil surpass him in intelligence.
				– Ernst Mach

Re: encoding in *compilation-buffer*

[tlanglois]

Peter Dyballa wrote:
> 
> 
> Which tool is actually emitting these codes? (I presume it's this  
> "javatolatex".) Does its documentation tell a bit about colours?
> 
> 

no gcc is emiting those codes. 
After a little googling I found a solution:
If I set export LC_ALL=C in a *shell* buffer, gcc emits normal ascii
characters.
But I don't know how to set that variable in *compilation* buffers
automatically.



-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30966005.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 19.02.2011 um 15:31 schrieb tlanglois:

> But I don't know how to set that variable in *compilation* buffers
> automatically.


You can customise the make command (I don't know the exact variable's  
name) and make it to something like:

	env LC_ALL=C make ...

You can reach the customisation interfaces from the Options ->  
Customize Emacs menu.

Another option is to launch GNU Emacs directly as 'env LC_ALL=C  
emacs ...' and not setting any language-environment.

--
Greetings

   Pete

»¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣
ɓuı̣ɥʇʎuɐ sı̣ pooɓ ʇɐɥʍ«

Re: encoding in *compilation-buffer*

[tlanglois]

So the problem is caused by environment settings that affect how gcc prints
messages.
Here is hello.c:  void main() { int a = 3 }
M- x shell then:
~/code/c$ gcc hello.c
hello.c: In function ‘main’:
hello.c:1: error: expected ‘,’ or ‘;’ before ‘}’ token
hello.c:1: error: expected declaration or statement at end of input
~/code/c$ export LC_CTYPE=C
~/code/c$ gcc hello.c
hello.c: In function 'main':
hello.c:1: error: expected ',' or ';' before '}' token
hello.c:1: error: expected declaration or statement at end of input

The solution is to set the variable when starting emacs. When I put (setenv
"LC_CTYPE" "C")
in my .emacs file everything is OK including when compiling with M-x compile
I don't know if setting this environment variable for the whole emacs
session may cause undesirable side effects.

Thibault


-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30968731.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 20.02.2011 um 02:30 schrieb tlanglois:

> The solution is to set the variable when starting emacs. When I put  
> (setenv
> "LC_CTYPE" "C")
> in my .emacs file everything is OK including when compiling with M-x  
> compile
> I don't know if setting this environment variable for the whole emacs
> session may cause undesirable side effects.


GNU Emacs will now interpret everything in 7-bit US-ASCII. Including  
file names. Putting compilation only in this mode (env LC_CTYPE=C  
<command>) should be sufficient.

--
Greetings

   Pete

Atheism is a non prophet organization.

Re: encoding in *compilation-buffer*

[tlanglois]

Peter Dyballa wrote:
> 
> GNU Emacs will now interpret everything in 7-bit US-ASCII. Including  
> file names. Putting compilation only in this mode (env LC_CTYPE=C  
> <command>) should be sufficient.
> 

Well, once more I have to confess my ignorance... How can I do that ?
Is there a before-compilation-hook that I can customize ?

The is a compilation-finish-functions hook
(http://www.gnu.org/s/emacs/manual/html_node/elisp/Standard-Hooks.html) but
I don't think it is what I need.


-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30970486.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[tlanglois]

tlanglois wrote:
> 
> Is there a before-compilation-hook that I can customize ?
> 

I found it finally !

All I have to do is put 
(setq compilation-environment "LC_CTYPE=C")
in .emacs

T.

-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p30970570.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Oleksandr Gavenko]

On 2011-02-20 13:15, tlanglois wrote:
> I found it finally !
>
> All I have to do is put
> (setq compilation-environment "LC_CTYPE=C")
> in .emacs
>
Docs say that this is a list:

(setq compilation-environment '("LANG=C"))

Your setup is working?

-- 
Best regards!

Re: encoding in *compilation-buffer*

[tlanglois]

Oleksandr Gavenko (aka gavenkoa) wrote:
> 
> (setq compilation-environment '("LANG=C"))
> 
> Your setup is working?
> 
Yes, you're right but curiously it is working.

-- 
View this message in context: http://old.nabble.com/encoding-in-*compilation-buffer*-tp30934972p31027419.html
Sent from the Emacs - Help mailing list archive at Nabble.com.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 20.02.2011 um 13:58 schrieb tlanglois:

> Well, once more I have to confess my ignorance... How can I do that ?
> Is there a before-compilation-hook that I can customize ?


It's much simpler! This variable exists in GNU Emacs:

	compile-command is a variable defined in `compile.el'.
	Its value is "time nice +11 make -k bootstrap"
	Original value was "make -k "
	
	  This variable is potentially risky when used as a file local  
variable.
	  This variable is safe as a file local variable if its value
	  satisfies the predicate `(lambda (a) (and (stringp a) (or (not  
(boundp (quote compilation-read-command))) compilation-read-command)))'.
	
	Documentation:
	Last shell command used to do a compilation; default for next  
compilation.
	
	Sometimes it is useful for files to supply local values for this  
variable.
	You might also use mode hooks to specify it in certain modes, like  
this:
	
	    (add-hook 'c-mode-hook
	       (lambda ()
		 (unless (or (file-exists-p "makefile")
			     (file-exists-p "Makefile"))
		   (set (make-local-variable 'compile-command)
			(concat "make -k "
				(file-name-sans-extension buffer-file-name))))))
	
	You can customize this variable.

I have it already customised, as you can see. To reach it you can use  
the Options menu with the sub-menu Customize Emacs or look up the  
documentation of compile-command per

	C-h v compile-command RET

and then click at the /customize/ hyper-link.

--
Greetings

   Pete

Only useless documentation transcends the first two laws.
				– Arnold's Third Law of Documentation

Re: encoding in *compilation-buffer*

[Oleksandr Gavenko]

On 2011-02-19 14:31, tlanglois wrote:
> Peter Dyballa wrote:
>>
>> Which tool is actually emitting these codes? (I presume it's this
>> "javatolatex".) Does its documentation tell a bit about colours?
>
> no gcc is emiting those codes.
> After a little googling I found a solution:
> If I set export LC_ALL=C in a *shell* buffer, gcc emits normal ascii
> characters.
> But I don't know how to set that variable in *compilation* buffers
> automatically.
>
Not automatically but for this purpose I use:

   M-x compile LANG=C make RET

when need output in EN locale (instead Russian). EN locale useful for
googling about occurred errors or if GCC lang settings misconfigured.

-- 
Best regards!

Re: encoding in *compilation-buffer*

[Alain Ketterlin]

tlanglois <tl@di.fc.ul.pt> writes:

> Peter Dyballa wrote:

>> Which tool is actually emitting these codes? (I presume it's this  
>> "javatolatex".) Does its documentation tell a bit about colours?

> no gcc is emiting those codes. 

Afaik, gcc doesn't do this. There must be some kind of "smart" wrapper
(usually named colorgcc) involved.

> After a little googling I found a solution:
> If I set export LC_ALL=C in a *shell* buffer, gcc emits normal ascii
> characters.
> But I don't know how to set that variable in *compilation* buffers
> automatically.

I've missed the start of the thread, but isn't
ansi-color-for-comint-mode supposed to solve this?

-- Alain.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

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.

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

--
Greetings

   Pete

Encryption, n.:
	A powerful algorithmic encoding technique employed in the creation of  
computer manuals.

Re: encoding in *compilation-buffer*

[Alain Ketterlin]

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.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 19.02.2011 um 18:12 schrieb Alain Ketterlin:

> 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


I see now: The C-u uses a comint-shell to run compilation process in  
it! (As the description states.) I simply did not knew this feature, a  
simple M-x was OK for me. (And probably will continue to be.) Thanks  
for this!

--
Greetings

   Pete

A morning without coffee is like something without something else.

Re: encoding in *compilation-buffer*

[Peter Dyballa]

Am 19.02.2011 um 18:12 schrieb Alain Ketterlin:

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

This mode has one disadvantage: You can't type "g" to repeat the  
compilation!

--
Greetings

   Pete

One-Shot Case Study, n.:
	The scientific equivalent of the four-leaf clover, from which it is  
concluded all clovers possess four leaves and are sometimes green.

Re: encoding in *compilation-buffer*

[Stefan Monnier]

> In compilation buffers it seems that non 8bit characters are used which
> truns error messages very hard to read :
> javatolatex.lex:93: error: expected �[39;49m\200\230;�[39;49m\200\231 before
> �[39;49m\200\230}�[39;49m\200\231 token

These look like escape sequences for things like coloring.


        Stefan