GNU bug report logs - #6416
next-error mis-highlights ocaml error message locations

Previous Next

Package: emacs;

Reported by: Jacques Le Normand <rathereasy <at> gmail.com>

Date: Sun, 13 Jun 2010 18:38:01 UTC

Severity: normal

Tags: moreinfo

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

Bug is archived. No further changes may be made.

Full log


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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jacques Le Normand <rathereasy <at> gmail.com>
Cc: 6416 <at> debbugs.gnu.org
Subject: Re: bug#6416: next-error mis-highlights ocaml error message locations
Date: Sun, 13 Jun 2010 18:46:25 -0400
> let foo : int =
>   "foo"
>   ^
>     "bar"

> it gives me the error

> File "/home/palomer/temp/test.ml", line 2, characters 1-21:
> ...

> which refers to:
>   "foo"
>   ^
>     "bar"

How does 1-21 refer to that, exactly?  The first " seems to be either at
position 2 or 3 depending on whether you start counting at 0 or 1, so
how can it be 1-21 rather than 2-<something>?

Second, the 1-21 range refers to bytes in the file, right?  (i.e. does
it count a TAB as 1 or as 8? how about a CR+LF?).

> next-error will try and highlight characters 1 to 21 on line 2. however,
> line 2 only contains 10 or so characters. This is because character 21
> actually refers to character 8 on line 4. Instead of highlighting 3 lines,
> only 1 line is highlighted.

Indeed, it's on purpose: I've never heard of a format of error messages
of a form like the one you describe, so compile.el makes no attempt to
handle such things, AFAIK.  Usually error messages that can refer to
several lines take a form like "LINE.COL - LINE'.COL'" or something like
that where the end-line is specified explicitly.

So in the present case, compile.el guesses that the 21 is really an
error (maybe because it refers to some other version of the file or
something) and just stops the line's end.  This behavior is The Right
Thing for most tools where such errors can never span multiple lines.

The questions above would help us figure out how to best adjust
compile.el and compilation-regexp-error-alist to handle such errors
correctly.  Of course, the better solution would be to change OCaml so
as to use more standard error messages, such as the GNU format, so it
would "just work".  So I suggest you also file a bug-report to the OCaml
guys that their error messages use a non-standard format and are
confusing since they only say "line 2, chars 1-21" even for a message
that spans lines 2-4.


        Stefan




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

Previous Next


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