search

c-blake / cligen

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at
https://c-blake.github.io/cligen/
ISC License
501 stars 23 forks source link

pre-generating input to help arguments #147

Closed disruptek closed 4 years ago

disruptek commented 4 years ago

https://github.com/disruptek/datamuse

I'm generating some constants for passing to dispatchMulti but it seems that they don't get consumed. I'm trying to match the constant table constructor format, but to no avail...

c-blake commented 4 years ago

Looking into it...Stay tuned.

c-blake commented 4 years ago

I think you just need a .toTable after your assoc-list {} literal. I can accept help={ literals } or help = a Table[string,string]. I show an example of the latter in test/PassValuesMulti.nim now. test/PassValues.nim already had one.

Honestly, I'm a bit surprised that const x = {1,2} even compiles to a seq[tuple[string, string]]. I'm not sure that was always the case. Anyway, I do not currently iterate and build a Table for a non-literal, non-Table, but toTable is there and handy and does that.

disruptek commented 4 years ago

Awesome; makes sense. Thanks again!

c-blake commented 4 years ago

You're welcome.

If it's ever an itch you (or anyone reading this) need to scratch to get rid of toTable, it would mostly be generalizing cligen.nim:parseHelps() and cligen.nim:parseShorts() to be able to work with this third kind of data input. Well, that and a way to distinguish const seq[tuple[]] from a const Table. Right now I just assume if we get an nnkSym then it must be a const Table. Some (any) kind of type checking on that symbol would help with a better error message. PRs for either the checking or generalization or both are welcome, but not high-priority, IMO.