Subject: bug#37633: Column part interpreted wrong in compilation mode

From: Lars Ingebrigtsen <[email-masked]>
Date: Sat, 23 Apr 2022 15:36:25 +0200

Bernd Paysan <[email-masked]> writes:

> Problems arise when tabs and UTF-8 glyphs are involved, e.g. compile
>
> ---------------test.c---------------
> void foo() {
> 	printf("test %i", b);
> 	printf("test你好 %i", c);
> }
> ---------------gcc test.c---------------
> -*- mode: compilation; default-directory: "~/tmp/" -*-
> Compilation started at Sat Oct  5 12:13:23

[...]

> test.c:3:26: error: ‘c’ undeclared (first use in this function)
>     3 |  printf("test你好 %i", c);
>       |                          ^

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Amusingly enough, gcc 11.2.0 said this to me

comp.c:4:31: error: 'c' undeclared (first use in this function)
    4 |         printf("test你好 %i", c);
      |                               ^

It's counting the leading TAB character as eight columns...  and then
counting the bytes of Chinese characters individually, ending up with a
column of 31.

So just using `filepos-to-bufferpos' wouldn't fix the current gcc.  We
could implement gcc's logic fully, but that's changing over time, and
other compilers surely have their own logic.  (I wouldn't be surprised
whether other compilers count characters instead of bytes in their
column outputs.)  And -finput-charset doesn't help with the column
calculation in gcc.

Since the issue is as messy as it is, I don't think there's anything
meaningful we can do here on the Emacs side, so I'm therefore closing
this bug report.  (If somebody has ideas that would work in general
here, please respond and we'll reopen.)

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