Character index vs Column number in GHC error messages

[Simon Marlow]

On 31 August 2005 07:55, Krasimir Angelov wrote:

> Quite recently GHC was changed to display the column number as well as
> the line number in all error messages. This is useful feature but I
> found the following difficulty with using it. All text editors that
> have built-in support for compilers, expect to find the line number in
> the reported error messages. Some of them support column number as
> well, but actually this isn't the column number but the character
> index in the current line. The difference comes from the tab
> characters which can have different width depending from the editor
> settings. For such reason all compilers, which I am aware of, display
> the character index instead of column number. I tried this with C#,
> Visual Basic and GNU CPP.  

GNU CPP reports the column number, not the char index, AFAICT.  Try the
attached file.

> GCC, Sun's Java compiler and Visual C++
> compiler are displaying only the line number. Using the character
> index the editor can unambiguously find the exact position where the
> error is independently from the current tab setting. GHC displays the
> column number instead and this confuses the editors. At least I tried
> this with Visual Studio and TextPad editor. I have modified the GHC
> parser so that it displays the character index instead of column
> number, but I am curious whether this is the preferred behaviour of
> the other compilers/editors. Any thoughts are appreciated.

Can I see your patch?  Remember that GHC has to calculate the column
number for the purposes of implementing layout correctly, even if it
only reports char indices in error messages.  If possible, I'd like to
make the behaviour configurable via a command-line switch.

The neatest way to do this would be to confine the changes to the lexer,
and to have all SrcLocs contain either column numbers or char indices
from the parser onwards (instad of trying to retain enough information
to provide both).  This means the lexer will have to retain additional
information about column positions, probably another integer
representing the number of tabbed columns.

Cheers,
	Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ctest22.c
Type: application/octet-stream
Size: 39 bytes
Desc: ctest22.c
Url : http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20050912/08d8010d/ctest22.obj