[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37633: Column part interpreted wrong in compilation mode
From: |
Lars Ingebrigtsen |
Subject: |
bug#37633: Column part interpreted wrong in compilation mode |
Date: |
Sat, 23 Apr 2022 15:36:25 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Bernd Paysan <bernd@net2o.de> 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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#37633: Column part interpreted wrong in compilation mode,
Lars Ingebrigtsen <=