[m-dev.] preferences for error contexts

Peter Wang novalazy at gmail.com
Fri May 15 20:00:06 AEST 2009


On 2009-05-15, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> 
> The replies to this email all seem to think that the old format and this
> proposed format are the only two alternatives. They are not.
> 
> At the very least, we could consider these formats and variations on them:
> 
> lalr.m:535: In clause for predicate ...
> lalr.m:535:  ...
> lalr.m:535: This file is in /home/pwa/Work/gws_shorter_errors/extras/moose.
> 
> The following errors refer to files in
> ERRORDIR /home/pwa/Work/gws_shorter_errors/extras/moose.
> lalr.m:535: In clause for predicate ...
> lalr.m:535:  ...

Neither of these would help anyone using vim's quickfix feature (and its
equivalent in emacs) without significant effort, nor the `gf' command.

[Elsewhere]
> This makes it safe to give the whole output from make or mmake to error as
> input, knowing that error will ignore the lines that are commands.

On the other hand, it is *fairly* safe, as continuation lines are always
indented by at least two spaces.

I don't think it's unreasonable to have our own error(1) program; as you
say, it's rarely installed anyway.  If we decide to only to use the new
format when necessary then other implementations will still work for the
most part.  People working on the Mercury compiler certainly wouldn't be
affected.

Peter

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list