* Compilation mode output is badly displayed
@ 2008-01-29 11:51 Francis Moreau
2008-01-29 17:06 ` Peter Dyballa
2008-01-29 20:47 ` Peter Dyballa
0 siblings, 2 replies; 11+ messages in thread
From: Francis Moreau @ 2008-01-29 11:51 UTC (permalink / raw)
To: help-gnu-emacs
Hello,
I'm currently trying to use the Compilation mode and all symbol names
are prefixed and suffixed with some escape sequences, well I think.
For example, I can see:
drivers/scsi/sata_via.c:1237: error: â\200\230struct inodeâ\200\231
has no member named â\200\230i_semâ\200\231
where the "drivers/scsi/sata_via.c" is correctly printed in red color.
Oh, yes I'm using emacs with -nw switch.
Can anyone help me to sort this out ?
Thanks
--
Francis
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-29 11:51 Compilation mode output is badly displayed Francis Moreau
@ 2008-01-29 17:06 ` Peter Dyballa
2008-01-29 17:29 ` Francis Moreau
2008-01-29 20:47 ` Peter Dyballa
1 sibling, 1 reply; 11+ messages in thread
From: Peter Dyballa @ 2008-01-29 17:06 UTC (permalink / raw)
To: Francis Moreau; +Cc: help-gnu-emacs
Am 29.01.2008 um 12:51 schrieb Francis Moreau:
> drivers/scsi/sata_via.c:1237: error: â\200\230struct inodeâ\200\231
> has no member named â\200\230i_semâ\200\231
You just need to switch your *compilation* buffer to display the
contents as UTF-8 contents. ``â\200\230´´ and ``â\200\231´´ are the
byte triplets that make the UTF representation of ``‘´´ and ``’´´, U
+2018 and U+2019. ``â\200\230´´ and ``â\200\231´´ are equivalent to
0xE28098 and 0xE28099.
--
Greetings
Pete
There is no worse tyranny than to force a man to pay for what he does
not want merely because you think it would be good for him.
– Robert Heinlein
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-29 17:06 ` Peter Dyballa
@ 2008-01-29 17:29 ` Francis Moreau
2008-01-29 20:27 ` Eli Zaretskii
0 siblings, 1 reply; 11+ messages in thread
From: Francis Moreau @ 2008-01-29 17:29 UTC (permalink / raw)
To: Peter Dyballa; +Cc: help-gnu-emacs
Hello,
On Jan 29, 2008 6:06 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> You just need to switch your *compilation* buffer to display the
> contents as UTF-8 contents. ``â\200\230´´ and ``â\200\231´´ are the
> byte triplets that make the UTF representation of ``'´´ and ``'´´, U
> +2018 and U+2019. ``â\200\230´´ and ``â\200\231´´ are equivalent to
> 0xE28098 and 0xE28099.
>
How do you do that ?
BTW why doesn't the *compilation* buffer display UTF8 contents by default
it the used enconding is UTF8 ?
Thanks
--
Francis
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-29 17:29 ` Francis Moreau
@ 2008-01-29 20:27 ` Eli Zaretskii
0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2008-01-29 20:27 UTC (permalink / raw)
To: help-gnu-emacs
> Date: Tue, 29 Jan 2008 18:29:04 +0100
> From: "Francis Moreau" <francis.moro@gmail.com>
> Cc: help-gnu-emacs@gnu.org
>
> > You just need to switch your *compilation* buffer to display the
> > contents as UTF-8 contents. ``â\200\230´´ and ``â\200\231´´ are the
> > byte triplets that make the UTF representation of ``'´´ and ``'´´, U
> > +2018 and U+2019. ``â\200\230´´ and ``â\200\231´´ are equivalent to
> > 0xE28098 and 0xE28099.
> >
>
> How do you do that ?
Try typing "C-x RET c UTF-8 RET" immediately before "M-x compile".
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-29 11:51 Compilation mode output is badly displayed Francis Moreau
2008-01-29 17:06 ` Peter Dyballa
@ 2008-01-29 20:47 ` Peter Dyballa
2008-01-30 8:28 ` Francis Moreau
[not found] ` <mailman.6736.1201681699.18990.help-gnu-emacs@gnu.org>
1 sibling, 2 replies; 11+ messages in thread
From: Peter Dyballa @ 2008-01-29 20:47 UTC (permalink / raw)
To: Francis Moreau; +Cc: help-gnu-emacs
Am 29.01.2008 um 12:51 schrieb Francis Moreau:
> Can anyone help me to sort this out ?
These typographic quotes come from GCC: can you try to put it into an
8- or 7-bit environment, like in:
env LC_CTYPE=FR_fr.ISO8859-15 make -k ...
env LANG=FR_fr.ISO8859-15 make -k ...
env LANG=FR_fr.ISO8859-15 LC_CTYPE=FR_fr.ISO8859-15 make -k ...
There must be a reason why GCC emits these typographic quotes. I am
sure outside an UTF-8 based environment GCC won't emit those Unicode
characters ...
--
Greetings
Pete
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-Benjamin Franklin, Historical Review of Pennsylvania.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-29 20:47 ` Peter Dyballa
@ 2008-01-30 8:28 ` Francis Moreau
[not found] ` <mailman.6736.1201681699.18990.help-gnu-emacs@gnu.org>
1 sibling, 0 replies; 11+ messages in thread
From: Francis Moreau @ 2008-01-30 8:28 UTC (permalink / raw)
To: Peter Dyballa; +Cc: help-gnu-emacs
On Jan 29, 2008 9:47 PM, Peter Dyballa <Peter_Dyballa@web.de> wrote:
>
> Am 29.01.2008 um 12:51 schrieb Francis Moreau:
>
> > Can anyone help me to sort this out ?
>
>
> These typographic quotes come from GCC: can you try to put it into an
> 8- or 7-bit environment, like in:
>
> env LC_CTYPE=FR_fr.ISO8859-15 make -k ...
It works fine
> env LANG=FR_fr.ISO8859-15 make -k ...
It works fine
> env LANG=FR_fr.ISO8859-15 LC_CTYPE=FR_fr.ISO8859-15 make -k ...
It works fine
>
> There must be a reason why GCC emits these typographic quotes. I am
> sure outside an UTF-8 based environment GCC won't emit those Unicode
> characters ...
>
From a shell:
$ echo $LANG
en_US.UTF-8
$ echo $LC_CTYPE
So it seems the reason why GCC emits UTF-8 encoding.
That said why doesn't Emacs notice the UTF-8 environment too ? It could
switch automatically to UTF-8 in this case ?
Thanks
--
Francis
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.6736.1201681699.18990.help-gnu-emacs@gnu.org>]
* Re: Compilation mode output is badly displayed
[not found] ` <mailman.6736.1201681699.18990.help-gnu-emacs@gnu.org>
@ 2008-01-30 16:42 ` Sven Joachim
2008-01-30 19:18 ` Peter Dyballa
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Sven Joachim @ 2008-01-30 16:42 UTC (permalink / raw)
To: help-gnu-emacs
On 2008-01-30 09:28 +0100, Francis Moreau wrote:
> From a shell:
>
> $ echo $LANG
> en_US.UTF-8
>
> $ echo $LC_CTYPE
>
>
> So it seems the reason why GCC emits UTF-8 encoding.
>
> That said why doesn't Emacs notice the UTF-8 environment too ? It could
> switch automatically to UTF-8 in this case ?
Normally it does, but you may have cruft in your init file that sets up
a non-UTF-8 environment. Look there for calls to
set-language-environment and standard-display-european.
Sven
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Compilation mode output is badly displayed
2008-01-30 16:42 ` Sven Joachim
@ 2008-01-30 19:18 ` Peter Dyballa
[not found] ` <mailman.6764.1201720817.18990.help-gnu-emacs@gnu.org>
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Peter Dyballa @ 2008-01-30 19:18 UTC (permalink / raw)
To: Sven Joachim, Francis Moreau; +Cc: help-gnu-emacs
Am 30.01.2008 um 17:42 schrieb Sven Joachim:
>> $ echo $LC_CTYPE
>>
>>
>> So it seems the reason why GCC emits UTF-8 encoding.
I don't see it ...
>>
>> That said why doesn't Emacs notice the UTF-8 environment too ? It
>> could
>> switch automatically to UTF-8 in this case ?
>
> Normally it does, but you may have cruft in your init file that
> sets up
> a non-UTF-8 environment. Look there for calls to
> set-language-environment and standard-display-european.
LC_CTYPE, the kind or type of characters used, is the most important
environment variable in this case. If it's not set, then everything
can happen. To me set-language-environment looks like an obsolete
call: does it change the language in which you are informed about a
character's, variable's, function's, or symbol's value? Is *calendar*
showing the legal holidays in your country in your language?
If UTF-8 is not correctly or sufficiently established, then it helps
a bit to have a
(prefer-coding-system 'utf-8)
--
Greetings
Pete
I wouldn't recommend sex, drugs or insanity for everyone, but they've
always worked for me.
– Hunter S. Thompson
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.6764.1201720817.18990.help-gnu-emacs@gnu.org>]
* Re: Compilation mode output is badly displayed
2008-01-30 16:42 ` Sven Joachim
2008-01-30 19:18 ` Peter Dyballa
[not found] ` <mailman.6764.1201720817.18990.help-gnu-emacs@gnu.org>
@ 2008-01-31 8:28 ` Francis Moreau
[not found] ` <mailman.6785.1201768127.18990.help-gnu-emacs@gnu.org>
3 siblings, 0 replies; 11+ messages in thread
From: Francis Moreau @ 2008-01-31 8:28 UTC (permalink / raw)
To: Sven Joachim; +Cc: help-gnu-emacs
On Jan 30, 2008 5:42 PM, Sven Joachim <svenjoac@gmx.de> wrote:
> Normally it does, but you may have cruft in your init file that sets up
> a non-UTF-8 environment. Look there for calls to
> set-language-environment and standard-display-european.
>
You're right !
In my .emacs, I have the following line:
(set-language-environment "Latin-1")
Should it be removed ?
FYI, here's the output of the command "describe-coding-system":
Coding system for saving this buffer:
Not set locally, use the default.
Default coding system (for new files):
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
Coding system for keyboard input:
u -- utf-8 (alias of mule-utf-8)
Coding system for terminal output:
u -- utf-8 (alias of mule-utf-8)
Defaults for subprocess I/O:
decoding: 1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
encoding: 1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
Priority order for recognizing coding systems when reading files:
1. iso-latin-1 (alias: iso-8859-1 latin-1)
2. windows-1252 (alias: cp1252)
3. mule-utf-8 (alias: utf-8)
4. mule-utf-16be-with-signature (alias: utf-16be-with-signature
mule-utf-16-be utf-16-be)
5. mule-utf-16le-with-signature (alias: utf-16le-with-signature
mule-utf-16-le utf-16-le)
6. iso-2022-jp (alias: junet)
7. iso-2022-7bit
8. iso-2022-7bit-lock (alias: iso-2022-int-1)
9. iso-2022-8bit-ss2
10. emacs-mule
11. raw-text
12. japanese-shift-jis (alias: shift_jis sjis cp932)
13. chinese-big5 (alias: big5 cn-big5 cp950)
14. no-conversion
Other coding systems cannot be distinguished automatically
from these, and therefore cannot be recognized automatically
with the present coding system priorities.
The following are decoded correctly but recognized as iso-2022-7bit-lock:
iso-2022-7bit-ss2 iso-2022-7bit-lock-ss2 iso-2022-cn
iso-2022-cn-ext iso-2022-jp-2 iso-2022-kr
Thanks for your support !
--
Francis
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.6785.1201768127.18990.help-gnu-emacs@gnu.org>]
end of thread, other threads:[~2008-01-31 15:38 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-01-29 11:51 Compilation mode output is badly displayed Francis Moreau
2008-01-29 17:06 ` Peter Dyballa
2008-01-29 17:29 ` Francis Moreau
2008-01-29 20:27 ` Eli Zaretskii
2008-01-29 20:47 ` Peter Dyballa
2008-01-30 8:28 ` Francis Moreau
[not found] ` <mailman.6736.1201681699.18990.help-gnu-emacs@gnu.org>
2008-01-30 16:42 ` Sven Joachim
2008-01-30 19:18 ` Peter Dyballa
[not found] ` <mailman.6764.1201720817.18990.help-gnu-emacs@gnu.org>
2008-01-30 19:41 ` Sven Joachim
2008-01-31 8:28 ` Francis Moreau
[not found] ` <mailman.6785.1201768127.18990.help-gnu-emacs@gnu.org>
2008-01-31 15:38 ` Stefan Monnier
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).