Some enums don't work

[Clyybber]

This example right here:

import cligen

type
  packMethod* = enum
    totalArea #The default
    shortSide
    longSide
    smallArea
    bottomLeft
    contactPoint

proc spritepacker(packMethod=totalArea) =
  discard

dispatch(spritepacker)

compiles fine and should work. But it does not:

./test --packMethod=totalArea
Bad enum value for option "packMethod". "totalArea" is not one of:
  totalArea shortSide longSide smallArea bottomLeft contactPoint

Maybe you meant one of:
  totalArea

Run with --help for more details.

This is kind of weird, since test/Enums.nim is working completely fine.

[c-blake]

Hmm. I have reproduced the trouble, but am not sure why it's failing. Give me a few minutes.

[c-blake]

Ok. I had code set up to handle normalizing the Nim identifiers for all correct enum values in cligen/argparse.nim:argparse[T: enum], but I did not actually apply a normalizing function to them. Oops. (Probably works in test program because all the literal idents used are already all lowercase with no '_'.)

Quick side question before I commit the fix - what do you think would be better in the error message to CLI users - the casing/spelling of the ident in the Nim code or the normalized spelling? In your example, suppose you had typed ./test -p totalAre. Would it be better to say

"totalare" not one of: totalarea shortside longside smallarea bottomleft contactpoint

or

"totalAre" not one of:  totalArea shortSide longSide smallArea bottomLeft contactPoint

? This is one of the rare cases where Nim's flexibly spelled identifier philosophy which is very Nim-idiosyncratic collides with expections of CLI users who may know nothing about Nim.

[c-blake]

(Right now it's set up to use whatever "apparently" (but not in CLI-actuality) case-sensitive convention the source code uses. That probably looks the best, but it leaves as "buried knowledge" that the CLI user can type it however they like.) Also, I just pushed a fix to address your basic problem.

[Clyybber]

I think it's better to suggest the non-normalized spelling, since it's often more readable.

[c-blake]

Yeah. I agree. We'll just leave the flexibility as knowledge to be acquired elsewise than making a typing mistake. :-) You should be good to go with #HEAD.

[c-blake]

(I went ahead and put a note towards the beginning of the --help-syntax cheat sheet. Maybe that's enough.)