bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Emacs.

On my new PC (Gentoo GNU/Linux), byte compiling in batch mode (e.g. with
make bootstrap in the master branch) is displaying warning messages with
symbols "quoted" by the invalid character glyph (a solid square) rather
than ` and '.  Presumably Emacs is attempting to use single curly
quotes.

This is ugly and not helpful.  A fix would be appreciated.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sat, 26 Aug 2017 13:06:08 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> On my new PC (Gentoo GNU/Linux), byte compiling in batch mode (e.g. with
> make bootstrap in the master branch) is displaying warning messages with
> symbols "quoted" by the invalid character glyph (a solid square) rather
> than ` and '.  Presumably Emacs is attempting to use single curly
> quotes.
> 
> This is ugly and not helpful.  A fix would be appreciated.

You need to figure out why the logic in startup--setup-quote-display
isn't working in your case.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Eli.

On Sat, Aug 26, 2017 at 17:09:17 +0300, Eli Zaretskii wrote:
> > Date: Sat, 26 Aug 2017 13:06:08 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > 
> > On my new PC (Gentoo GNU/Linux), byte compiling in batch mode (e.g. with
> > make bootstrap in the master branch) is displaying warning messages with
> > symbols "quoted" by the invalid character glyph (a solid square) rather
> > than ` and '.  Presumably Emacs is attempting to use single curly
> > quotes.
> > 
> > This is ugly and not helpful.  A fix would be appreciated.

> You need to figure out why the logic in startup--setup-quote-display
> isn't working in your case.

I don't think the calling of that function is pertinent; there is only
one call of it, and that is inside "(unless noninteractive ...)".
Presumably noninterative will be non-nil in batch mode.

Perhaps the problem is that that function (or some equivalent) isn't
being called, and Emacs is outputting non-displayable characters
regardless.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sat, 26 Aug 2017 17:06:59 +0000
> Cc: 28242@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Perhaps the problem is that that function (or some equivalent) isn't
> being called, and Emacs is outputting non-displayable characters
> regardless.

No, I think the problem is in the function using_utf8, called from
'main'.  Does it return true in your case?  If so, what does
terminal-coding-system return in your case in the -batch invocation,
and what is the value of locale-coding-system in that case?

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Eli.

On Sat, Aug 26, 2017 at 21:12:04 +0300, Eli Zaretskii wrote:
> > Date: Sat, 26 Aug 2017 17:06:59 +0000
> > Cc: 28242@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Perhaps the problem is that that function (or some equivalent) isn't
> > being called, and Emacs is outputting non-displayable characters
> > regardless.

> No, I think the problem is in the function using_utf8, called from
> 'main'.  Does it return true in your case?

I haven't worked out how to hook up gdb to a batch mode Emacs yet, but
surely using_utf8 will return non-zero.  I _am_ using utf8.

> If so, what does terminal-coding-system return in your case in the
> -batch invocation, and what is the value of locale-coding-system in
> that case?

In an interactive session, terminal-coding-system is utf-8-unix and
locale-coding-system is also utf-8-unix.

But I would be disturbed if my batch mode session didn't report
utf-8-unix, or something similar.  It's running on an up to date
GNU/Linux system.

Surely Emacs doesn't assume from the use of UTF8 that curly quotes are
displayable?  Those quotes are merely two characters from several
hundred thousand, and not all of these are going to be displayable.  On
a Linux tty, as I use, there is a maximum of 256 displayable glyphs.
Most UTF8 characters aren't displayable.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sat, 26 Aug 2017 19:24:31 +0000
> Cc: 28242@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > No, I think the problem is in the function using_utf8, called from
> > 'main'.  Does it return true in your case?
> 
> I haven't worked out how to hook up gdb to a batch mode Emacs yet

 $ gdb ./emacs
 ...
 (gdb) break using_utf8
 (gdb) r -batch ... <rest of arguments here>

> > If so, what does terminal-coding-system return in your case in the
> > -batch invocation, and what is the value of locale-coding-system in
> > that case?
> 
> In an interactive session, terminal-coding-system is utf-8-unix and
> locale-coding-system is also utf-8-unix.
> 
> But I would be disturbed if my batch mode session didn't report
> utf-8-unix, or something similar.  It's running on an up to date
> GNU/Linux system.

If you locale's codeset is UTF-8, then how come your terminal cannot
display those quote characters?

> Surely Emacs doesn't assume from the use of UTF8 that curly quotes are
> displayable?  Those quotes are merely two characters from several
> hundred thousand, and not all of these are going to be displayable.  On
> a Linux tty, as I use, there is a maximum of 256 displayable glyphs.
> Most UTF8 characters aren't displayable.

We are not interested in all of the Unicode characters, we are only
interested in a few of them.

Anyway, I think it works for everyone else, the question is why
doesn't it work for you?

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Eli.

On Sat, Aug 26, 2017 at 22:40:04 +0300, Eli Zaretskii wrote:
> > Date: Sat, 26 Aug 2017 19:24:31 +0000
> > Cc: 28242@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > No, I think the problem is in the function using_utf8, called from
> > > 'main'.  Does it return true in your case?

> > I haven't worked out how to hook up gdb to a batch mode Emacs yet

>  $ gdb ./emacs
>  ...
>  (gdb) break using_utf8
>  (gdb) r -batch ... <rest of arguments here>

> > > If so, what does terminal-coding-system return in your case in the
> > > -batch invocation, and what is the value of locale-coding-system in
> > > that case?

> > In an interactive session, terminal-coding-system is utf-8-unix and
> > locale-coding-system is also utf-8-unix.

> > But I would be disturbed if my batch mode session didn't report
> > utf-8-unix, or something similar.  It's running on an up to date
> > GNU/Linux system.

> If you locale's codeset is UTF-8, then how come your terminal cannot
> display those quote characters?

The particular font in use (I haven't configured one since setting up
this new box) simply doesn't have mappings for the curlies.  I don't know
why that should be.  My one theory is that the designer of the font
decided to use a long diagonal line rather than a reversed comma shape
for grave (`), making it unsuitable for doubling up as the left curly
quote.  Or something like that.

But there are likely many, many PCs around using this font, or others
like it.

> > Surely Emacs doesn't assume from the use of UTF8 that curly quotes are
> > displayable?  Those quotes are merely two characters from several
> > hundred thousand, and not all of these are going to be displayable.  On
> > a Linux tty, as I use, there is a maximum of 256 displayable glyphs.
> > Most UTF8 characters aren't displayable.

> We are not interested in all of the Unicode characters, we are only
> interested in a few of them.

> Anyway, I think it works for everyone else, the question is why
> doesn't it work for you?

I haven't (yet) set up a terminal font for Emacs, I'm just using some
default font.  Everything else, so far, seems to work with it.  It seems
to me the problem is that Emacs is outputting curly quotes to the screen
without having determined that they can be displayed properly.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Paul Eggert]

What happens if you run the following shell commands?

echo invalid program >t.c
gcc t.c

On my machine GCC outputs diagnostics with curved quotes, like this:

t.c:1:1: error: unknown type name ‘invalid’
...

What do you see on your console? If you see solid squares or other glitches 
rather than curved quotes, then the problem is not specific to Emacs.


> On my new PC (Gentoo GNU/Linux), byte compiling in batch mode (e.g. with
> make bootstrap in the master branch) is displaying warning messages with
> symbols "quoted" by the invalid character glyph (a solid square) rather
> than ` and '.
...
> My one theory is that the designer of the font
> decided to use a long diagonal line rather than a reversed comma shape
> for grave (`),

These two passages seem inconsistent. One says you’re seeing a solid square; the 
other a long diagonal line.

For what it’s worth, I don’t observe the problem on my Ubuntu 16.04.3 LTS 
console. I see curved quotes. I don’t remember doing anything to configure my 
console. Here is my /etc/default/console-setup file: it may help you to set up 
your computer. On Ubuntu, the command ‘sudo dpkg-reconfigure console-setup’ 
configures this file.

# CONFIGURATION FILE FOR SETUPCON

# Consult the console-setup(5) manual page.

ACTIVE_CONSOLES="/dev/tty[1-6]"

CHARMAP="UTF-8"

CODESET="guess"
FONTFACE="Fixed"
FONTSIZE="8x16"

VIDEOMODE=

# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Paul.

On Sun, Aug 27, 2017 at 01:16:45 -0700, Paul Eggert wrote:
[ .... ]

> > On my new PC (Gentoo GNU/Linux), byte compiling in batch mode (e.g. with
> > make bootstrap in the master branch) is displaying warning messages with
> > symbols "quoted" by the invalid character glyph (a solid square) rather
> > than ` and '.

[ .... ]

> For what it’s worth, I don’t observe the problem on my Ubuntu 16.04.3 LTS 
> console. I see curved quotes. I don’t remember doing anything to configure my 
> console. Here is my /etc/default/console-setup file: it may help you to set up 
> your computer.

This bug report is not about setting up _my_ computer.  It's an attempt
to make Emacs compatible with what's out there in the field.  Emacs
should not require a special console setup to display error and warning
messages properly.

I think the font in use on my new box must be part of Linux itself,
rather than being a default chosen by Gentoo and then loaded during
booting.  Emacs ought to be compatible with Linux.

Why are these curly quotes being output without first checking that the
device they're being output to can display them?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sun, 27 Aug 2017 09:16:54 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: 28242@debbugs.gnu.org
> 
> Why are these curly quotes being output without first checking that the
> device they're being output to can display them?

Paul, is it possible to use for this purpose a technique similar to
what you coded in calculate_glyph_code_table?  That is, call that
special ioctl function, then look in the mapping it returns for the
curly quote characters, and if they aren't there, reset
text_quoting_flag?  Would that work?

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Paul Eggert]

Eli Zaretskii wrote:
> is it possible to use for this purpose a technique similar to
> what you coded in calculate_glyph_code_table?  That is, call that
> special ioctl function, then look in the mapping it returns for the
> curly quote characters, and if they aren't there, reset
> text_quoting_flag?  Would that work?

Although it might work if Emacs is run directly from a Linux console, I doubt 
whether it'd work in general. The ioctl needs a file descriptor, and which file 
descriptor should Emacs try? Stdout? Stderr? What if the output of Emacs is 
being sent to a file or pipe, and some other program later displays the text?

I'd like to see what GCC does before worrying about this too much. Also I'd like 
to know why Alan sometimes sees block squares and sometimes diagonal lines.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Paul.

On Sun, Aug 27, 2017 at 09:46:32 -0700, Paul Eggert wrote:
> Eli Zaretskii wrote:
> > is it possible to use for this purpose a technique similar to
> > what you coded in calculate_glyph_code_table?  That is, call that
> > special ioctl function, then look in the mapping it returns for the
> > curly quote characters, and if they aren't there, reset
> > text_quoting_flag?  Would that work?

> Although it might work if Emacs is run directly from a Linux console, I doubt 
> whether it'd work in general.

Does it need to work in general?  Other methods are clearly not working
at all, in general.

> The ioctl needs a file descriptor, and which file descriptor should
> Emacs try? Stdout? Stderr?

Both.  If both are known to be able to display curlies, use them,
otherwise stick to the ASCII quotes.

> What if the output of Emacs is being sent to a file or pipe, and some
> other program later displays the text?

Play it safe.  Somebody redirecting output to a file is going to want to
analyse it.  Make it easy for that person, and use the ASCII quote
characters.

> I'd like to see what GCC does before worrying about this too much. Also I'd like 
> to know why Alan sometimes sees block squares and sometimes diagonal lines.

Block squares arise from an attempt to display curly quotes and other
undisplayable characters.  Diagonal lines are the font's representation
of ASCII grave (0x60), and arise from typing the key to the left of "1".

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Cc: 28242@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 27 Aug 2017 09:46:32 -0700
> 
> The ioctl needs a file descriptor, and which file 
> descriptor should Emacs try? Stdout? Stderr?

We are talking about messages in -batch, so stderr.

> What if the output of Emacs is 
> being sent to a file or pipe, and some other program later displays the text?

I don't think we should care.  The primary goal is to have batch-mode
messages to the screen display legibly.  If another program later
examines the results, it's a problem for that other program.  In
particular, if that other program is Emacs, we already have the
solution for displaying these quotes in interactive sessions.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> What if the output of Emacs is 
>> being sent to a file or pipe, and some other program later displays the text?
>
> I don't think we should care.  The primary goal is to have batch-mode
> messages to the screen display legibly.  If another program later
> examines the results, it's a problem for that other program.  In
> particular, if that other program is Emacs, we already have the
> solution for displaying these quotes in interactive sessions.

If I skim this thread correctly, I think the general sentiment was that
this wasn't something that should be fixed, so I'm closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Paul Eggert]

Alan Mackenzie wrote:
> Why are these curly quotes being output without first checking that the
> device they're being output to can display them?

Please test whether GCC generates curved quotes in the same environment, using 
the recipe I suggested in my previous email. That could help us diagnose the 
problem.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

On Sun, Aug 27, 2017 at 09:40:48 -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > Why are these curly quotes being output without first checking that the
> > device they're being output to can display them?

> Please test whether GCC generates curved quotes in the same environment, using 
> the recipe I suggested in my previous email. That could help us diagnose the 
> problem.

This is the Emacs list, not the GCC list.  The problem is already
diagnosed: Emacs is outputting non-displayable characters.

Now please answer the question: why are curly quotes being output without
first checking that the device they're being output to can display them?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Glenn Morris]

If your system has the same issue with gcc warnings (and if you choose
not to answer the question, a cynic like me will assume it does), then
your system is misconfigured, and it's not important to improve Emacs's
support for it.

Don't set LANG to a UTF8 locale if your font doesn't support it.
gcc went through the same issue years ago. Eg

https://stackoverflow.com/questions/6537520/strange-characters-present-in-gcc-compilation-output-message-on-console

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Glenn.

On Sun, Aug 27, 2017 at 12:47:21 -0400, Glenn Morris wrote:

> If your system has the same issue with gcc warnings (and if you choose
> not to answer the question, a cynic like me will assume it does), ...

It does.

> ... then your system is misconfigured, and it's not important to
> improve Emacs's support for it.

I've looked into this.  My system is currently using the standard Linux
font, the one baked into the kernel.  I would have thought it rather
important to support properly - there will be lots of similarly
"misconfigured" systems around.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sun, 27 Aug 2017 17:05:04 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: 28242@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>
> 
> I've looked into this.  My system is currently using the standard Linux
> font, the one baked into the kernel.  I would have thought it rather
> important to support properly - there will be lots of similarly
> "misconfigured" systems around.

What non-ASCII characters does that font support?

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Eli.

On Sun, Aug 27, 2017 at 20:21:24 +0300, Eli Zaretskii wrote:
> > Date: Sun, 27 Aug 2017 17:05:04 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: 28242@debbugs.gnu.org, Paul Eggert <eggert@cs.ucla.edu>

> > I've looked into this.  My system is currently using the standard Linux
> > font, the one baked into the kernel.  I would have thought it rather
> > important to support properly - there will be lots of similarly
> > "misconfigured" systems around.

> What non-ASCII characters does that font support?

Let me cite the comment at the top of the pertinent Linux source file,
/usr/src/linux-4.13-rc3/drivers/tty/vt/cp437.uni:

#
# Unicode table for IBM Codepage 437.  Note that there are many more
# substitutions that could be conceived (for example, thick-line
# graphs probably should be replaced with double-line ones, accented
# Latin characters should replaced with their nonaccented versions,
# and some upper case Greek characters could be replaced by Latin),
# however,
# I have limited myself to the Unicodes used by the kernel ISO 8859-1,
# DEC VT, and IBM CP 437 tables.
#

It seems to be mainly ASCII, Latin-1, with lots of miscellaneous
graphics characters, including the single and double line thingies,
sufficient to support mutt, for example.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Eli Zaretskii]

> Date: Sun, 27 Aug 2017 17:31:31 +0000
> Cc: rgm@gnu.org, 28242@debbugs.gnu.org, eggert@cs.ucla.edu
> From: Alan Mackenzie <acm@muc.de>
> 
> # Unicode table for IBM Codepage 437.

Hilarious.  DOS is dead for so many years, and Linux couldn't come up
with anything better than the worst DOS codepage in history...

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Paul Eggert]

Alan Mackenzie wrote:
> On Sun, Aug 27, 2017 at 12:47:21 -0400, Glenn Morris wrote:
> 
>> If your system has the same issue with gcc warnings (and if you choose
>> not to answer the question, a cynic like me will assume it does), ...
su
> It does.

Then you'll need to fix your setup to get GCC working, as well as Emacs.


> Diagonal lines are the font's representation
> of ASCII grave (0x60), and arise from typing the key to the left of "1".

So this font cannot even display ASCII? Another annoyance. While you're fixing 
that you might as well fix the curved quotes.

I don't see this as rising to something that we need to worry about. Emacs is 
behaving consistently with other programs. Even with the display glitches, the 
batch diagnostics are still quite intelligible, so the glitches are merely an 
annoyance.

If despite my advice we decide to support this misconfigured font, then we need 
to change the default batch quoting style to 'straight', not 'grave'. This is 
because the font in question cannot display grave accent either. It would be a 
simple matter to use the 'straight' quoting style for all batch invocations. I'm 
not in favor of this, though.

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Alan Mackenzie]

Hello, Paul.

On Sun, Aug 27, 2017 at 11:43:16 -0700, Paul Eggert wrote:
> Alan Mackenzie wrote:
> > On Sun, Aug 27, 2017 at 12:47:21 -0400, Glenn Morris wrote:

> >> If your system has the same issue with gcc warnings (and if you choose
> >> not to answer the question, a cynic like me will assume it does), ...

> > It does.

> Then you'll need to fix your setup to get GCC working, as well as Emacs.

I will get around to that in good time.  It remains a problem for all
those working with the standard Linux font.

> > Diagonal lines are the font's representation
> > of ASCII grave (0x60), and arise from typing the key to the left of "1".

> So this font cannot even display ASCII?

It can.  I suggest you try it out first, before making such wild
statements.

> Another annoyance. While you're fixing that you might as well fix the
> curved quotes.

> I don't see this as rising to something that we need to worry about. Emacs is 
> behaving consistently with other programs.

There was a time when Emacs was a leader, not a follower.  Seems such
times have passed.

> Even with the display glitches, the batch diagnostics are still quite
> intelligible, so the glitches are merely an annoyance.

Annoyances should be fixed.  It's the lack of annoyances which makes (or
made) Emacs such an attractive program in the first place.

> If despite my advice we decide to support this misconfigured font, then we need 
> to change the default batch quoting style to 'straight', not 'grave'. This is 
> because the font in question cannot display grave accent either.

Stop being idiotic.

> It would be a simple matter to use the 'straight' quoting style for
> all batch invocations. I'm not in favor of this, though.

How about allowing the user to configure this, in good old fashioned
Emacs fashion?

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28242: Batch mode compiling: Error messages are displayed with "invalid character" glyph bounding symbols.

[Paul Eggert]

Alan Mackenzie wrote:

>> Then you'll need to fix your setup to get GCC working, as well as Emacs.
> 
> I will get around to that in good time.

When that happens, the issue should be fixed for both GCC and Emacs, even in an 
UTF-8 locale.

> It remains a problem for all
> those working with the standard Linux font.

It is by no means the "standard" font. Hardly anybody uses it on Linux any more. 
I have to go to some work to try it out myself, on either Ubuntu or Fedora. The 
few people who use Linux console fonts are generally aware of these issues and 
it is not hard to address them.

> There was a time when Emacs was a leader, not a follower.

In this case the issue seems to be whether Emacs should "lead" us back to the 
1980s, when PCs had inferior fonts.

> Stop being idiotic.

It is not at all an idiotic suggestion. ISO 646 permits countries to usurp grave 
accent. For example, old-design French monitors display grave accent as a micro 
sign (µ), to conform to the French NF Z 62-010 profile for ISO 646. Again, I 
don't think Emacs should take trouble to cater to old designs like this. 
However, if we do it then it's safer and more portable for Emacs to avoid 
routine use of grave accent in its batch diagnostics, as grave accent is 
mishandled more often than apostrophe is. This is because ISO 646 usurps grave 
accent but not apostrophe.

> How about allowing the user to configure this

It is configurable already; just set LC_ALL=C in the environment. This should 
fix the issue for both Emacs and GCC.

PS. Rhetoric like "Stop being idiotic" is not helpful here.