Justify citekeys in list command

[omangin]

trafficstars

As mentinoned by @wflynny in #109:

citekey justification on listing could be added (e.g. adding some string formatting to pretty.py: paper_oneliner)[...]. Something like: u'[{citekey:>30}] {descr} {tags}'.

Any though for or against this? We might want a config option to overcome this as well as a mechanism for not indenting citekeys over a limit length. The indentation can easily be determined from the list of citekeys to print.

[wflynny]

FWIW, I have this implemented in my personal build and it greatly improves readability for me.

We might want a config option to overcome this as well as a mechanism for not indenting citekeys over a limit length.

This is a good idea. Maybe a flag to enable indenting and another to config option to define indent size / maximum indentation size before not indenting. Assign this to me and I'll try to get a PR going over the weekend.

[wflynny]

Thoughts on specific formatting?

A: [citekey1    ] description
B: [citekey2]     description

I've also added configuration options for the following two things:

1. wrapping long lines at specified width (and for wrapping to respect the indentation)
2. change citekey delimiters, e.g. [citekey] vs _citekey_ vs ^citekey$, etc.

By default, output will look identical to current.

[omangin]

Good point. I was initially more inclined toward B but A seems to make more sense visually. No strong opinion though.

For the wrapping, you could also add an auto mode that uses the value in the $COLUMNS environment variable or the output from tput cols. For consistance with the coloring behavior, it however needs to be disabled when stdout is piped to another process (the same way it is done currently for colors).

I am not against the citekey delimiter option although I am not sure it is really useful. We might postpone it to make it part of a more flexible option such as enabling a custom format string for paper listings.

[benureau]

The underscore delimiters _citekey_ might be confusing, as underscore can be part of a citekey. Then comes the decision whether we should guard users against this or not. We could also consider switching to a format such as:

citekey | description

Which saves one character, and would probably look nice with layout B. But that's not critical.