GNU bug report logs - #37633
Column part interpreted wrong in compilation mode

Previous Next

Package: emacs;

Reported by: Bernd Paysan <bernd <at> net2o.de>

Date: Sat, 5 Oct 2019 15:45:01 UTC

Severity: normal

Tags: wontfix

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bernd Paysan <bernd <at> net2o.de>
To: bug-gnu-emacs <at> gnu.org
Cc: anton <at> mips.complang.tuwien.ac.at
Subject: Column part interpreted wrong in compilation mode
Date: Sat, 05 Oct 2019 13:12:34 +0200
[Message part 1 (text/plain, inline)]
Compilers like gcc and others (e.g. gforth) output file:line:column on each 
error or warning.  However, “column” here is really the byte offset into the 
line (starting at 1).

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

gcc test.c
test.c: In function ‘foo’:
test.c:2:2: warning: implicit declaration of function ‘printf’ [-Wimplicit-
function-declaration]
    2 |  printf("test %i", b);
      |  ^~~~~~
test.c:2:2: warning: incompatible implicit declaration of built-in function 
‘printf’
test.c:1:1: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’
  +++ |+#include <stdio.h>
    1 | void foo() {
test.c:2:20: error: ‘b’ undeclared (first use in this function)
    2 |  printf("test %i", b);
      |                    ^
test.c:2:20: note: each undeclared identifier is reported only once for each 
function it appears in
test.c:3:26: error: ‘c’ undeclared (first use in this function)
    3 |  printf("test你好 %i", c);
      |                          ^

Compilation exited abnormally with code 1 at Sat Oct  5 12:13:23
---------------snip---------------

When you click on test.c:2:20, it gets you to the second t in 'test'; if you 
click on test.c:3:26, you end up on the '%'.  The expected result would be to 
have the cursor on 'b' and 'c'.

The problem has been discussed here two years ago:

https://www.reddit.com/r/emacs/comments/5m3i59/
ask_remacs_get_compile_mode_to_treat_column/

Suggested solution: Use byte-to-position to calculate the position in 
compilation-move-to-column.

Since debugging environments can also control Emacs e.g. through emacsclient 
+line:column file, I suggest adding a pattern that indicates that column here 
really means byte position, too, e.g. +line/byte or +line,byte or such. Or 
just interpret it as byte position, too.  gedit e.g. counts a tab as 1 if you 
open a file with +line:column options, but counts one UTF-8 glyph also as 1 
(which is not how compilers count).

Some programming languages convert unicode glyphs and other characters into 
internal character types (e.g. JavaScript), and then the gedit behavior or the 
behavior with compilation-error-screen-columns set to nil is probably ok.  
It's just that we need a byte mode here, too. True and false is not enough.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o id: kQusJzA;7*?t=uy <at> X}1GWr!+0qqp_Cn176t4(dQ*
https://net2o.de/
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 3 years and 86 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.