GNU bug report logs - #18342
24.3.93; jumping to compilation error location gives the wrong column

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18342 in the body.
You can then email your comments to 18342 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.93; jumping to compilation error location gives the wrong column
Date: Thu, 28 Aug 2014 14:31:37 +0400

In GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0)
Repository revision: 117453 eliz <at> gnu.org-20140819185629-52e2mzy5tucd0tic

When stepping through compilation errors `C-x `' jumps to a code
location with correct line, but incorrect column: it actually jumps to a
column previous to the right one.  Checked with emacs -Q and Java files
compilation.

Emacs is built from current emacs-24 bzr branch.

-- 

    Filipp

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 18342 <at> debbugs.gnu.org
Subject: Re: bug#18342: 24.3.93;
 jumping to compilation error location gives the wrong column
Date: Thu, 28 Aug 2014 09:22:20 -0400

> When stepping through compilation errors `C-x `' jumps to a code
> location with correct line, but incorrect column: it actually jumps to a
> column previous to the right one.  Checked with emacs -Q and Java files
> compilation.

> Emacs is built from current emacs-24 bzr branch.

There are columns and columns.  So most likely the problem is that Emacs
doesn't know which columns the Java compiler uses.

Are these columns 0-based or 1-based?  Do they count characters, bytes,
or width?  (e.g. what does TAB count as? what about non-ASCII chars in
utf-8?)

These can partly be supported via compilation-first-column and
compilation-error-screen-columns (tho Emacs has no support for counting
columns in bytes).  Arguably, rather than variables, these settings
should be part of the compilation-error-regexp-alist entries since it
depends on the compiler in use.


        Stefan

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

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: 18342 <at> debbugs.gnu.org
Subject: Re: bug#18342: 24.3.93;
 jumping to compilation error location gives the wrong column
Date: Fri, 06 Mar 2015 02:41:30 +0300

Ok, I fixed it by adding the following to the java-mode-hook:

(set (make-local-variable 'compilation-first-column) 0)

But the problem of the common (lack of?) knowledge between emacs and the
compiler continues to exist.

However, if we set aside the TAB problem (everywhere I worked nobody
used TAB in source code), there doesn't seem to be a big problem:

The column numbers emitted by the compiler most probably mean "screen
columns" - just where you made an error in the source file.  I don't
know of compilers which do differently (I usually work only with
Oracle's Java compiler so I'm not the best person to state that).

If emacs and the compiler agree on source file encoding (and they should
be tuned to agree), then emacs just needs to go that count of chars
forward from the beginning of line.  The only things that remains -
whether to start from 0 or from 1 - is already handled by looking at
`compilation-first-column'.

Regarding `compilation-error-regexp-alist', the
`compilation-first-column' probably could be there, but then it should
be something like `compilation-compiler-var-alist' instead :)

There are unclear cases e.g. with maven: what if we use Oracle JDK which
outputs columns beginning with 0 and then change to another JDK which
outputs beginning with 1?  Would maven correct it's output?  I doubt so.
Then we should have two items in the alist: maven-oracle and maven-smth.

It'd be good to mention `compilation-first-column' in the manual.

Filipp

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 18342 <at> debbugs.gnu.org
Subject: Re: bug#18342: 24.3.93;
 jumping to compilation error location gives the wrong column
Date: Fri, 06 Mar 2015 10:34:10 +0200

> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
> Date: Fri, 06 Mar 2015 02:41:30 +0300
> 
> The column numbers emitted by the compiler most probably mean "screen
> columns" - just where you made an error in the source file.  I don't
> know of compilers which do differently (I usually work only with
> Oracle's Java compiler so I'm not the best person to state that).
> 
> If emacs and the compiler agree on source file encoding (and they should
> be tuned to agree), then emacs just needs to go that count of chars
> forward from the beginning of line.

Character counts don't depend on encoding.  Only byte counts depend on
encoding.

So I'm not sure what you are trying to say here.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 18342 <at> debbugs.gnu.org
Subject: Re: bug#18342: 24.3.93;
 jumping to compilation error location gives the wrong column
Date: Fri, 06 Mar 2015 12:54:47 -0500

> Regarding `compilation-error-regexp-alist', the
> `compilation-first-column' probably could be there, but then it should
> be something like `compilation-compiler-var-alist' instead :)

I tend to agree that the "first-column" info should probably be placed
alongside the regexp (same for compilation-error-screen-columns, BTW).

> There are unclear cases e.g. with maven: what if we use Oracle JDK which
> outputs columns beginning with 0 and then change to another JDK which
> outputs beginning with 1?  Would maven correct it's output?  I doubt so.
> Then we should have two items in the alist: maven-oracle and maven-smth.

Indeed, there are "hard" cases.  Luckily, column positions usually
aren't so terribly important, so being off by a few chars is annoying
but bearable.


        Stefan

Message #22 received at 18342-done <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 18342-done <at> debbugs.gnu.org
Subject: Re: bug#18342: 24.3.93;
 jumping to compilation error location gives the wrong column
Date: Wed, 11 Mar 2015 03:19:42 +0300

On 06/03/2015 12:54 -0500, Stefan Monnier wrote:

>> Regarding `compilation-error-regexp-alist', the
>> `compilation-first-column' probably could be there, but then it should
>> be something like `compilation-compiler-var-alist' instead :)
>
> I tend to agree that the "first-column" info should probably be placed
> alongside the regexp (same for compilation-error-screen-columns, BTW).
>
>> There are unclear cases e.g. with maven: what if we use Oracle JDK which
>> outputs columns beginning with 0 and then change to another JDK which
>> outputs beginning with 1?  Would maven correct it's output?  I doubt so.
>> Then we should have two items in the alist: maven-oracle and maven-smth.
>
> Indeed, there are "hard" cases.  Luckily, column positions usually
> aren't so terribly important, so being off by a few chars is annoying
> but bearable.

It's even worse, as I've just discovered: we have a "checkstyle" plugin
for Maven which, yes, checks style.  And maven outputs its errors with
differently based column numbers (starting with one).  This and javac
invocation happens within one compilation, so it seems currently we have
no way of distinguishing between them and applying different settings.

Anyway, I'm closing this bug for now.

Filipp

Previous Next

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