The asterisks are what define a symbol as "exported" from a module -- every symbol is private to the module scope by default, but able to be exported by applying the asterisks to it; types.nim is funky because I was exploring a slightly different file/module structure (and having a singular place for top-level shared types that most other modules import is quite useful at times, and gets around circular dependencies), except it does end up looking slightly odd!
That's it. For the most part, one would just export the symbols from given modules as needed (and a lot of the properties on some of the ref object types are needlessly exported, too, which makes it worse)
One other thing is that the {.compile.} pragma in term.nim is not needed anymore, as Nim's stdlib has added a lot of those in[0], but it does show how easy it is to bridge between the two languages (and I'm not much of a C developer!)
