better yaml parsing

[pd93]

This PR greatly improves the error reporting of YAML issues by surfacing the real parsing errors from yaml.v3 and providing a syntax highlighted snippet of the error and its location. It also provides a clickable link to the error location (if using a supported editor terminal like VSCode).

Syntax highlighting is provided through chroma and I have added a custom theme that looks good for terminals that only support 8 colours.

Some examples:

[vmaerten]

Good job! It's way more clear now 🎉

[vmaerten]

(Nothing to see with this PR, but what is your taskd command ? 😄 )

[pd93]

what is your taskd command ? 😄

Hey @vmaerten, it's just a function I have defined in my dotfiles that helps me out with development:

taskd () {
        pushd "$DEV/github.com/go-task/task" &> /dev/null
        go build -o "$HOME/bin/taskd" ./cmd/task
        res=$? 
        popd &> /dev/null
        if [ $res -ne 0 ]
        then
                echo "\x1b[31mFailed to build taskd\x1b[0m"
                return 1
        fi
        "$HOME/bin/taskd" "$@"
}

Essentially, it will build the task binary, place it in my ~/bin and then (if it succeeds) call it with any arguments I gave. It allows me to easily test checked out code without having to manually install development versions of task every time I make a change. Not doing this can get quite annoying as I regularly use a release version of task for work.

Sidenote: You might think "why not just use go run ... instead?". I used to do this, but the go binary obscures things like exit codes and can actually change behaviour in some subtle ways. It's best to test with a properly built binary.

[andreynering]

I liked the idea, this is a great QoL improvement!

I noticed that actual syntax errors still show the usual way. That's a possible improvement to be done in the future:

[andreynering]

I rebased to fix a conflict.

[pd93]

I noticed that actual syntax errors still show the usual way. That's a possible improvement to be done in the future:

@andreynering I did look into this while doing this PR, but those errors are created by the YAML lexer rather than the parser. This makes it a bit more difficult to intercept the errors as we don't have access to the yaml.Node when the error first hits our code. However, maybe there is another way. Worth taking a look in the future.

This alternative library also exists which provides this kind of error handling out-of-the-box. However, it does not implement the same interfaces and would mean redoing all our unmarshalers which is a bit annoying.