Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:
> It may be possible to do something like this instead (untested), but
> I'm not sure it's worth the complexity:
>
> $checked .= substr($body, $start, $pos - $start);
> $checked .= ' ' unless $checked =~ /\s$/;
> $checked .= "$erropenERR $err$errclose";
> $checked .= ' ' unless $pos + 1 >= length($body) ||
> substr($body, $pos + 1, 1) =~ /\s/;
I think the complexity you mention is the updates to existing code
to get to the above end state? Using some setup like ...
($erropen, errclose) =
$colored_output ? ("?!", "?!") : ("<RED>", "<RESET>");
... and then using a code like the above would be quite
straightforward and the end result cannot become simpler than that
;-)
> As first implemented, there was no structured "problem description".
> chainlint originally just output a stream of raw parse tokens (not the
> original test text), and when a problem was discovered the "?!...?!"
> annotations were embedded directly in the output stream. This was
> still the case even when colored output was implemented[1]; in fact,
> the annotations were colored after-the-fact by searching for "?!...?!"
> in the output stream. It was only when chainlint was taught to output
> the original test text verbatim[2] that problem descriptions became
> structured data.
Exactly.
Thanks.
