In this post:
- I research by going beyond research.
- I do end up figuring out which bits are difficult, though.
- And get a plan specifically for the next time.
Here's where the blog publisher is now:
- A single, awkwardly-named python script with no if __name__ == '__main__': stanza, that I "use" by invoking it in interactive mode and calling functions.
- Many functions call subprocesses, but do not check the result.
- The script is supposed to be a click frontend to a bunch of libraries for manipulating different kinds of directory trees, but it only depends on click, without helpfully using it, and is a single script.
- Various paths specific to my current setup are hardcoded into the script.
- The invocation is not instantaneous, and if something goes wrong, I have to look at the output like a savage to know that it didn't work.
It turns out that handling the first three of these was pretty easy. And the last one wasn't a big deal either, though my solution could use some refinement. "Research" here seems to mean "just try stuff". Experimentation is a kind of research, right?
In that vein, let's see what happens if I just try to put together my ideas for a syntax definition...
Here's what happens:
- Formatting string literals, control flow, access modifiers, and builtin constants were all easy.
- Getting hashed syntax highlighting as I want it looks like it needs a different syntax definition. Yaaaay.
- For some reason, the hashed syntax highlighting did turn some of the source to these blog posts into rainbow goop.
Therefore, the hard problems, currently, are addressing the hardcoded constants in the blog publisher (hard because I don't have any other users to get feedback on how this should work from), writing a python syntax file worthy of my syntax highlighting, and finding a more robust way to call AppleScript from Python.
The syntax file is the highest priority, so I guess I'll be looking into that.
So far, I've mostly copied the current Python syntax definition from Sublime Text, stripped out Python-2-specific syntax, and left myself notes on a few things I want to work differently.
Basically, aside from giving all names a handy scope, I want to:
- Consider the different kinds of name somewhat differently. (It seems to me that it makes some kind of sense to distinguish between "names reserved by the language" (and perhaps distinguish between known and unknown versions of such names), "names scoped to a class", "names private by convention", and "names public by convention")
- Consider docstrings as embedded reStructuredText instead of comments. (Also, get or make a new reStructuredText syntax definition.)
- Parse comments somewhat, and highlight directives. (So, call out in some way, the shebang line, the encoding specification, notes, typing directives, and possibly other tools.)
Next time, I try to get some of these specific things done, in the custom package I made to test this stuff out.