Support storing more than one postal address per contact about ppl

[pigmonkey]

I'm liking the idea of having numeric identifiers for more than just addresses. I've gone through and updated my contacts' phone numbers a couple times recently. First to set a type, then to specify preferred numbers. Typing out the phone number whenever I want to do anything to it gets old, and I already need to do a ppl phone johnd first so that I can get the phone number.

To set a preferred phone number, right now I need to do this:

$ ppl phone johnd
    123-555-1234 (cell)
    123-555-5678 (work)
$ ppl phone johnd 123-555-1234 -p

It would save keystrokes if I could also do something like this:

$ ppl phone johnd
1.    123-555-1234 (cell)
2.    123-555-5678 (work)
$ ppl phone johnd 1 -p

[henrycatalinismith]

I know what you mean, that can be a bit of a pain. Incidentally, I recently spent some time expanding on the bash completion code you contributed, so that it can autocomplete things like this.

$ ppl phone james<tab>        # pressing tab shows suggested matches
[email protected]     [email protected]
$ ppl phone james jamie<tab>  # pressing tab autocompletes the remaining address
$ ppl phone james [email protected]

Since doing that, it's been much less frustrating. I'm not sure how this whole thing will turn out just yet, though. On the one hand., I'm extremely dubious of numerical identifiers. In the past I've used CLI todo list software that relied on them, and it was a never-ending usability nightmare remembering all these arbitrary numbers that constantly shifted around when things were created and deleted. I found myself having to re-output the list every other command.

But on the other hand, I plan to build them into ppl post anyway, and I'll try to keep my mind open when I do. Once they're built into that command, I am intrigued to see how I feel about numerical identifiers. If nothing else it'll be an interesting challenge trying to make them work better than my previous experiences with them, and if it works out well enough, who knows.