Drop Async Implementation

[Andrei15193]

There is actually little need for async implementation of this library. The initial reasoning for this was to make it easy to keep an UI responsive when parsing a large text. This can easily be done using Task.Run() as such:

partial class MyForm
{
    // ...

    private void _ButtonClick(/* ... */)
    {
        Task.Run(
            () =>
            {
                var parser = new CreoleParser();
                var result = parser.Parse(MyText);
                var visitor = new MyCustomVisitor();
                result.Accept(visitor);
            }
        );
    }
}

And can be extended with CancellationToken to support cancellation:

partial class MyForm
{
    // ...

    private async void _ButtonClick(/* ... */)
    {
        using (CancellationTokenSource = new CancellationTokenSource())
            try
            {
                await Task.Run(
                    () =>
                    {
                        var parser = new CreoleParser();
                        var result = parser.Parse(MyText);
                        var visitor = new MyCustomVisitor(CancellationTokenSource.Token);
                        result.Accept(visitor);
                    },
                    CancellationTokenSource.Token
                );
            }
            catch (TaskCancelledException)
            {
                // ...
            }
        CancellationTokenSource = null;
    }

    private void _CancelButtonClick(/* ... */)
        => CancellationTokenSource?.Cancel();
}

In addition to having a synchronous implementation, this can make it easier for the parser to be ported to other languages with more ease (e.g.: JavaScript). While it is questionable whether an async implementation works better in that case, since JS is single-threaded, and chopping the execution into multiple methods can have a small impact on performance (context switching) but allows the UI to still be responsive as it can handle callbacks in between the chopped methods.

In this case the parsing can be delegated to a back-end (in case of very large text fields) and for relatively small or medium amounts of text the parser to be fast enough to transform the text without having a visible impact on the user experience. In the latter case some benchmarks would be useful to know appropriate limits where the parser may start to take a longer time to process considering multiple cases: simple text, moderate rich text (not a lot of rich text elements, something that would be expected), most difficult rich text the parser has to handle all put together (worst case scenario). This benchmark should help provide some useful information about what the limits are and whether it is acceptable for the user to have have these potential lags. It should cover multiple devices from low-end smartphones to high-end ones, tablets, laptops and PCs.

[Andrei15193]

In addition to having a synchronous implementation, this can make it easier for the parser to be ported to other languages with more ease (e.g.: JavaScript). While it is questionable whether an async implementation works better in that case, since JS is single-threaded, and chopping the execution into multiple methods can have a small impact on performance (context switching) but allows the UI to still be responsive as it can handle callbacks in between the chopped methods.

In this case the parsing can be delegated to a back-end (in case of very large text fields) and for relatively small or medium amounts of text the parser to be fast enough to transform the text without having a visible impact on the user experience. In the latter case some benchmarks would be useful to know appropriate limits where the parser may start to take a longer time to process considering multiple cases: simple text, moderate rich text (not a lot of rich text elements, something that would be expected), most difficult rich text the parser has to handle all put together (worst case scenario). This benchmark should help provide some useful information about what the limits are and whether it is acceptable for the user to have have these potential lags. It should cover multiple devices from low-end smartphones to high-end ones, tablets, laptops and PCs.

Should be treated in a separate issue with help wanted label.

[Andrei15193]

In addition to having a synchronous implementation, this can make it easier for the parser to be ported to other languages with more ease (e.g.: JavaScript). While it is questionable whether an async implementation works better in that case, since JS is single-threaded, and chopping the execution into multiple methods can have a small impact on performance (context switching) but allows the UI to still be responsive as it can handle callbacks in between the chopped methods.
In this case the parsing can be delegated to a back-end (in case of very large text fields) and for relatively small or medium amounts of text the parser to be fast enough to transform the text without having a visible impact on the user experience. In the latter case some benchmarks would be useful to know appropriate limits where the parser may start to take a longer time to process considering multiple cases: simple text, moderate rich text (not a lot of rich text elements, something that would be expected), most difficult rich text the parser has to handle all put together (worst case scenario). This benchmark should help provide some useful information about what the limits are and whether it is acceptable for the user to have have these potential lags. It should cover multiple devices from low-end smartphones to high-end ones, tablets, laptops and PCs.

Should be treated in a separate issue with help wanted label.

Done, created #13.