Re: Fun with WebAda/GNAT

[dsmith@clark.net (Doug Smith)]

I was going to change the subject line, but it seems even more
appropriate now:

In article <dewar.840403100@schonberg>, dewar@cs.nyu.edu (Robert Dewar) wrote:

> [snip]
> 
> But are you really sure you want to see
> 
> /nile.a/ada/ada/gnatbugs/fixed/0000-020/q.adb:2:03: "x" conflicts with
> declaration at /nile.a/ada/ada/gnatbugs/fixed/0000-020/q.ads:2

[Answering for myself:]

Eventually, yes. I would like gnat to begin moving toward some standard
markup of error messages and other output. Obviously, the markup I would
recommend is HTML. Currently, WebAda takes the output of the compiler and
echos it as pre-formatted text (which it most certainly is). But there
is nothing to prevent the output from indicating more information in a
form that can be rendered in a readable way:

<pre>
  <a
href="surfada?file=/nile.a/ada/ada/gnatbugs/fixed/0000-020/q.adb">q.adb</a>:2:03:
<b>x</b> conflicts with declaration at <a
href="surfada?file=/nile.a/ada/ada/gnatbugs/fixed/0000-020/q.ads">q.ads</a>:2
</pre>

If your news reader does not render the html above, it would look something
like:

  q.adb:2:03: x conflicts with declaration at q.ads:2

Which does not necessarily make the problem apparent. However, browsers
will indicate the target of a link when pointing at that link. Of course,
I've made a link that uses my surfada tool, and GNAT would probably need
to define an environment variable or configuration file which could be
changed to use a different tool (which would have to recognize the file
parameter).

> we think not. I suppose one could put in a switch, but there are lots of
> switches already, and typically no one reads the documentation carefully,
> so no one knows about them!

In this case, the switch would indicate that a standard markup is used
for tools to render the output. This allows you to add italics, color,
etc. Not everyone gets excited about color, but some people find it
helpful. An alternative would be to define your own markup which a
tool (such as WebAda) could translate into html (or whatever) and
render for the developer.

> I certainly have never had trouble with the lack of full paths in error
> messages, and it is not something that any of our users have ever requested.
> Error messages are always a matter of balance, and we tend to trying to keep
> them short and content rich.
> 
> [snip]

Good point. And towards that goal, much of the information in an error
message can be rendered more efficiently when that information is in
markup. In the example above, a browser would render a single line, yet
contain significantly more information than the text only message.

Doug

p.s. The phrase "conflicts with declaration" could also be linked to a page
     providing detailed explanations and references to the LRM, tutorials,
     etc. ACT would need only map each error message to a unique file
     path which the Ada community could begin to maintain for everyone's
     benefit. (I'm trying to ease the burden on the ACT folk so that it
     might be more feasible to implement my proposal)