I apologize, the numbers in the example were erroneous. Take this example
instead:

let foo: int =
  "foo"
  ^
    "bar"

gives the error:
File "/home/palomer/temp/test.ml", line 2, characters 2-21:


ocamlc starts counting at 0. it counts newlines and tabs as 1. I obtained
these results empirically.  The previous example means:
"the third character from the start of line 2 to the 22nd character from the
start of line 2"

I've filed a bug report with ocaml developers (and have even suggested a
simple fix.) I can't say how inclined they will be to fix it. The bug id
is 0005070. The mantis url is http://caml.inria.fr/mantis/

thank you for your quick response,
-- Jacques

On Sun, Jun 13, 2010 at 6:46 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > 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
>