Syntax Highighting - Planning 2018-08-15

Tags:
By Max Woerner Chase

In this post:


I'm able to kind of muddle through with basic syntax changes by just tweaking small areas until they work right, but I've got some changes I want to make to my "Edge" syntaxes that are much bigger and riskier. Since I want to make "Edge" actually capable of highlighting the stuff I want, that means I need a safety net in the form of tests. I also need a better name than "Edge", seriously.

Because I don't have hands-on experience with writing syntax tests, and I don't know how Sublime Text specifically behaves with them, for my next post I just want to create some writeups of different test cases that I can then actually create for the next post after that.

To get stuff for tests, I want to first focus on the language specification, then on the documentation of built-in functions and classes, then on standard library code that defines behavior for reserved method names not covered by the previous areas.

For each test, I want to get a minimal syntactically valid snippet of code, followed by more elaborate constructions that bear more resemblance to code "in the wild". For example, numeric literals should be tested on their own, then in the context of stuff like top-level constants, default function arguments, and literals within a function. Each subsection of documentation should have its own writeup of what tests it suggests, if any, and if there are tests, each subsection gets its own test file. These ideas might change as I get more hands-on experience, but I hope they're solid.

I don't know how much I'll get to this week, but one thing I want in the future is to make an effort to support subsets of old functionality; for example, Python 2 reserves a different set of method names than Python 3.


Next time, I write up syntax test specifications based on the Python documentation.