snap list/find output

[John Lenton]

As we add richer options to snaps and want to rightly expose them in
the commandline output, the question is how to make it usable.

The output of `snap list`, for example, needs to show, in a single
line that could reasonably be as narrow as 80 columns wide:

some are text fields, with reasonably long limits (e.g. 32 chars for version):

name
version
revision
developer name, at least if different from publisher name
summary

(when querying the store we could also have "price" for example)

and some that are flagish:

is it private?
is it devmode?
try?
has it been paid for?
does it provide services, and are they running ok?
does it have updates available?
is the revision we're on "pinned" because of it being manually requested?
it has updates available, and we're not going there because
...they're devmode and we aren't? [this might be invisible to the client]
...we tried and had to rollback?
...rollback was done by user?

there's also some system-level things we want to output on snap list:

is a reboot required?
is it a devmode-only thing? (e.g. running without apparmor in the kernel)
is the system tainted or otherwise dirty? (nothing done for this yet,
but needs thinking aboot)

i'm also probably forgetting things.

One thing I *don't* want us to do is have something like the header on
`dpkg -l`:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================

I also don't want us to punt on the problem by not exposing this info
and having a `-o` option à la ps; the defaults should be good enough
(especially given that the REST API is straightforward enough if
developers need more control) (not to say that we don't add something
like -o down the line, but it's cornercase).

So, having said all this, I think we can get very good results by
using adaptive layout with a combination of colours, a bit of unicode,
and per-column shortening strategies.

A lot of this working hinges on there being a clear precedence in the
"flagish" columns. For example,

First off, if the output isn't a tty, just output tab-separated
non-shortened columns. Easy for programs to poke at. Otherwise:

Never shorten name nor revision. If just those two don't fit, tough
luck. But don't use a header for Revision (as most often that will be
wider than the revision); just r%d (after version, if it fit).
Put all flagish things under a single (e.g.) "Notes" column. If a ",
"-separated list of the most succint way of describing each flag
doesn't fit, put "see info" (or e.g. "👉info" if that works). Assume
you've shortened it for now. Colourize the line based on what's in the
notes (e.g. red if it demands attention). Maybe also add an
exclamation mark if it does!
If you're already at the width, that's it. Otherwise, while each bit
of info doesn't go over the width,
Shorten version down to the localised length of "Version", using an
ellipsis (… U+2026 HORIZONTAL ELLIPSIS) in the middle.
Shorten developer name down to the localized length of "Developer",
with an ellipsis at the end.
Add summary, ellipsised at the end.
Go back and lengthen "notes" if possible.

that, to my mind, works.

I can implement a PoC of this so we can play with it if you'd rather,
but I didn't want to dive into doing that first before we checked
whether I was sane.

Anyway. Bikeshed away!