bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37633: Column part interpreted wrong in compilation mode


From: Eli Zaretskii
Subject: bug#37633: Column part interpreted wrong in compilation mode
Date: Sun, 06 Oct 2019 20:16:43 +0300

> From: Bernd Paysan <bernd@net2o.de>
> Cc: 37633@debbugs.gnu.org, anton@mips.complang.tuwien.ac.at
> Date: Sat, 05 Oct 2019 21:24:17 +0200
> 
> > But the column numbers are counted in the compiler output, and no one
> > said that the compiler output must be encoded the same as the source
> > file.
> 
> The column numbers are written as decimal digits in the compiler output.  
> They 
> are not even calculated, they are just extracted.
> 
> Indeed, the compiler output can be in a different encoding, but it doesn't 
> matter.  The navigation that needs to change is in the source code file.  
> This 
> is compiler output from compiling an iso-latin encoded file, the compiler 
> output itself is utf-8:
> 
> test-iso.c:3:23: error: ‘c’ undeclared (first use in this function)
>     3 |  printf("test��� %i", c);
>       |                       ^
> 
> The 23(-1) are the numbers of bytes to get from the start of line to the 
> missing variable 'c'.  The three � are there, because the compilation buffer 
> contains invalid characters now.  They are iso-latin characters, invalid in 
> utf-8.  But this is irrelevant.  All the compilation mode does is extract the 
> test-iso.c (file name), 3 (line number) and 23 (byte index).  Navigation 
> happens in test-iso.c, it's a file (the C compiler can't access emacs 
> buffers), autodetection is pretty reliable.

Sorry, now I'm confused.  Does the compiler count bytes in its output
(where a Latin-1 line could be recoded in UTF-8, and thus have a
different number of bytes), or does it count bytes in the original
file (in this case encoded in Latin-1, i.e. 1 byte per character)?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]