1computer1 / errata Goto Github PK

Right now, all the source lines are just put into an array and indexed into when necessary. This of course forces the entire list of lines, which is not the best for performance nor space. Instead, we could collect all the required lines into an IntMap or similar by using the line numbers and styling options from the given Errata.

The makeSourceLines function within the renderSourceLines function contains the logic for which lines are required. It might also be worth investigating refactoring the entire renderSourceLines function so that it isn't so big.

There should be options for enabling/disabling the various decorations and whatnot.

• styleEnableDecorations to enable/disable the underlines, connectors, and labels on source lines.
• styleEnableLinePrefix to enable/disable the vertical bar and line number behind each line.
• styleEnableHook (in PointerStyle) to enable/disable the "hook" for labels that drop down, and start labels directly under the connector when disabled.
• styleCompact to enable/disable the padding lines above and below the source code, but only when there is no underline/label below e.g. combined with styleEnableDecorations = False. Implemented with stylePaddingTop and stylePaddingBottom.

There are some places where trailing whitespace shows up (see some of the later golden test files). It is not very noticeable obviously, but it is a bit smelly to have. We should get rid of all trailing whitespace in the pretty printer.

It could be useful to have options for the amount of "extra" lines to show in the message.

This includes:

• styleLeadingLines for lines before the first pointer.
• styleTrailingLines for lines after the last pointer.
• styleExtraLinesAfter and styleExtraLinesBefore for lines in between two lines that are far apart in the same block. Includes lines after the former and lines before the latter. Currently hardcoded at 2 and 1 respectively.

There are currently no tests for Errata other than running the examples and checking if they look right. We can automate this with golden tests, tests which output a file that can be compared to in the future. We can also add some unit tests for some of the helper functions.

Golden tests can probably be done with hspec-golden. Unit tests, then, with just hspec.

Hello! This is a great library. I use it in my simple-parser library to show pretty errors (example). Would you consider adding it to Stackage? I can make the PR in the stackage repo if you +1 it. Typically the burden as a library author is just getting an issue notification if your package falls out of the package set due to constraint failures. I doubt this will happen with the few common dependencies you have. Thanks!