Feature request: support multi-level yaml

[vkkodali]

If I understand correctly, multilevel yamls are not supported currently.
For example, I would like to do the following:

appname:
- -input:
  - <file>

instead of doing:

appname:
- -input

appname -input:
- <file>

Is that something you would be able to implement?

[DannyBen]

Well, it is a good idea of course.
However, this complicates things to a point where the YAML becomes much less readable.

If I take the example YAML from the README, and nest it, it might look like this:

mygit:
  --help:
  --version:
  status:
    --help:
    --verbose:
    --branch:
    $(git branch 2>/dev/null):
  init:
    --bare:
    <directory>:
  commit:
    <file>:
    --help:
    --message:
    --all:
    -a:
    --quiet:
    -q:
  checkout:
    "*--branch":  &branches
      - $(git branch 2>/dev/null)
    "*-b": *branches

Note the last checkout node - where flags in this case (--branch), need to be prefixed with *.

I wonder if we should consider replacing YAML with a simple indented file, like this:

mygit
  --help -h
  --version -v
  status
    --help -h
    --verbose
    --branch
    $(git branch 2>/dev/null)
  init
    --bare
    <directory>
  checkout
    * --branch -b
      $(git branch 2>/dev/null)

[DannyBen]

How do you feel about this format?

mygit:
- --help
- --version
- init:
  - --bare
  - <directory>
- checkout:
  - +--force
  - +--branch: &branches
    - $(git branch --format='%(refname:short)' 2>/dev/null)
  - +-b: *branches

which looks like this in the "flat" format:

mygit:
- "--help"
- "--version"
- init
- checkout
mygit init:
- "--bare"
- "<directory>"
mygit checkout:
- "+--force"
- "+--branch"
- "+-b"
mygit checkout*--branch:
- "$(git branch --format='%(refname:short)' 2>/dev/null)"
mygit checkout*-b:
- "$(git branch --format='%(refname:short)' 2>/dev/null)"

Note the use of + as an alternative to *, since YAML has a special meaning for * in keys.

# this...
- checkout:
  - "*--force"

# ... can be written like this (note no quotes, which is prettier)
- checkout:
  - +--force

Also need to note that this "flattener" I created, treats strings that start with + or * differently, by merging them with the previous prefix without sapce:

mygit checkout*--branch

# instead of

mygit checkout *--branch

Since this is a standalone converting class - I believe I can make it work, and still support the current flat format.

Thoughts?

[vkkodali]

Thank you, that's a very very quick response!
The flat format looks fine to me. I can give it a spin and let you know how it works.

[DannyBen]

The flat format looks fine to me. I can give it a spin and let you know how it works.

You mean the nested format, yes? The flat format is the one we have now.
#76 contains this change if you want to try it.

I am updating the README now.

[vkkodali]

You mean the nested format, yes? The flat format is the one we have now.

Yes, that's what I meant.

#76 contains this change if you want to try it.

Can I install the updated version by running gem install completely? Or, is there some other way I should install it?

[DannyBen]

Well, no installing from source is slightly more complicated.
Tell you what - I can release a prerelease, and then it will be something like gem install completely --version ....

Will that work for you?

[vkkodali]

Yup, works for me

[DannyBen]

Ok - you can now install it:

gem install completely --pre

and then you can generate a sample nested configuration with:

completely init --nested

The nested syntax is documented towards the end of the README.

[vkkodali]

It works!! 🎉
I am able to generate a nested file and pass it on to completely to produce a completion script that's identical to the previous one.

[DannyBen]

Nice. And the syntax + docs are ok I am guessing?
If so, I will release later this week.

[vkkodali]

Yup, the docs and syntax are fine too. To be clear, I did not make any big changes to my workflow -- just generated a yaml with nested strings (using + instead of *) and ran completely generate to produce the completion file. Worked like a charm.

[DannyBen]

Yes - this was the intention.
Keep the issue open - I will close it upon release.

Thanks for the suggestion and for testing.