misc feedback on implementation
- [x] use assert/doAssert/raise instead of `quit` (https://forum.nim-lang.org/t/4042)

- [x] use quoteShell everywhere relevant; adding `"` is not always correct and also read uglier eg:
```
      {.passC: "-I\"/Users/foo/include\"".}
     #  whereas quoteShell would, here, give simply
      {.passC: "-I/Users/foo/include".}
```

- [x] group all globals in nimterop/globals.nim into a single object

- [x] pass global to procs that need it instead of having globals

- [x] each un-handled AST element should call a (user-settable) callback instead of just doing nothing, eg via
`else: return` and `else: discard`
- [x] tests: use unittest check,require instead of assert or doAssert

- [x] use `type AstRef = ref Ast` instead of `ref Ast` everywhere (removed the Ast altogether)

- [x] inconsistent: sometimes you use default c, sometimes default cpp; 
```
proc process(path: string, mode="cpp", pretty = true)
macro cIncludeCcAddStdDir*(mode = "c")
```
ideally, you'd have a single default define once (DRY)
```
let modeDefault = "c" 
proc process(path: string, mode=modeDefault, pretty = true)
macro cIncludeCcAddStdDir*(mode = modeDefault)
```

## controversial
- [x] generate translations by operating on NimNode instead of string; it's less error prone; parseStmt can always be used when needed (also can be used during this transition)
`pFunctionDeclarator` for example is a bit ugly using string manipulations

EDIT: actually a proc with NimNode, IIRC, has to be compileTime only ; that would be a limitation compared to using strings which have flexibility of being usable at either runtime or compiletime; need to think more...
although maybe Nim could be patched to allow runtime NimNode, from which we can get a string (eg via `repr`) in case user wants a generated nim code at runtime

> genotrance: now that toast does all of it, this isn't possible anymore.

## feedback that maybe belongs to treesitter
- [ ] `class` seems wrongly accepted for C header files

> genotrance; not supported yet by toast - C++ can be tracked separately.

## comparison with calypso approach

- [ ] can nimterop eventually allow mapping C++ function templates to nim generic procs ? eg, mapping `std::vector<T>` 
that's feasible with https://wiki.dlang.org/Calypso in D

> genotrance: need to see what tree-sitter generates in this case but should be feasible

- [ ] some ideas from https://github.com/Syniurge/Calypso/issues could be reused

# scratch below here

- [x] option to return generated nim code as a string (user can then do whatever, eg dump it to stdout)
- [ ] option add line info (pointing to .h sources) as doc comment for each translated declaration
- [ ] option add debug line info (pointing to .h sources) (eg as dwarf?) as done in Nim code, which allows you to have a nice debug experience under gdb/lldb
- [x] allow (as option) specifying language, eg: `cImport("foo.h", lang = c)` ; `cImport("foo.h", lang = cpp)`
- [ ] allow `cFlag(“-Dfoo -Dbar -Ifoobar ”)` instead of `cDefine` (and maybe even `cIncludeDir `) etc

> cImport() already has `flags` which can do this

- [ ] can nimterop replace `py2nim`? cf https://forum.nim-lang.org/t/2705

> No plans to cover Python - already pyimport and nimpy exist

- [ ] how can treesitter correctly disambiguate C++ code that depends on semantic analysis, eg : `<<` which could mean operator << or double `<` template

> Will see how this works once we start C++ work

## links
-  [ ] https://news.ycombinator.com/item?id=9640912
> you can even build a Nim macro that does a "Go get" and Nim developers can use Golang libraries right in their code as imports

> Likewise with Go, will track separately if we ever get to it.