bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Filipp Gunbin]

In GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0)
Repository revision: 117453 eliz@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

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Stefan Monnier]

> 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

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Filipp Gunbin]

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

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@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.

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Stefan Monnier]

> 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

bug#18342: 24.3.93; jumping to compilation error location gives the wrong column

[Filipp Gunbin]

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