bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Environment variable to turn off carets


From: Frank Heckenbach
Subject: Re: Environment variable to turn off carets
Date: Mon, 12 Jan 2015 23:30:35 +0100

>    What I gather from this is, that the proposal might be generalized a
>    little. Instead of just dealing with carets, the variable could say
>    "no redundant output" or something to this effect. Meaning that the
>    output will be processed or interpreted by a tool rather than
>    directly read by a human.
> 
> You make good points, and I like this approach better, something like
> "plain" GNU error/warning messages.  Then if error messages with
> embedded URLs to the relevant standard are introduced, that would fall
> under the same environment variable and would "magically" vanish when
> one uses this plain form of output.

That's an interesting case. An editor may not actually want the URLs
suppressed if it has a way of e.g. letting the user browse to them.

Of course, they're strictly speaking redundant, since the editor
could use the error/warning text to find the relevant standard. But
logically this information doesn't belong in the editor, but in the
compiler which outputs them. So this kind of redundancy might be
acceptable or even desirable.

In fact, what would really be desirable might be a unique markup for
URLs (and the text they refer to), so the editor can find them
reliably.

Given that, this approach could also be used for carets. If marked
uniquely, the editor could simply ignore them. (Whereas recognizing
and filtering them out by heuristic doesn't seem so trivial, ISTR
I've seen caret lines like "   ^^^", "   ^---^", " ^~", "   ~ ^"
etc. Maybe /^([ ^~-])+$/ would catch all caret lines, but I'm not
too comfortable with it.)

In any case, such unique markup (for various interesting parts of
the output) seems rather like a bigger project which I fear nobody
has really time and interest to implement any time soon. (And it
would also require an indication to activate since it would confuse
normal command-line output, which brings us back to the environment
variable.)

What I gather from this is to make the variable more extensible.
Instead of a simple yes/no for carets, we could have (names just
tentative:

nothing (as now, possibly depend on command-line arguments)

OUTPUT_FORMATTING=no-caret (as in my original proposal)

OUTPUT_FORMATTING=markup (could be implemented later whenever
someone wants so; or maybe more specific modes, whatever seems
useful then)

OUTPUT_FORMATTING=no-caret,markup (for backward compatibility in the
future when some programs support "markup" and others don't)

So what programs should now would be something like this:

  const char *formatting = getenv ("OUTPUT_FORMATTING");
  if (formatting && strstr (formatting, "no-caret"))
    // turn off carets

Regards,
Frank



reply via email to

[Prev in Thread] Current Thread [Next in Thread]