Proposal to change the channels display of snap info


#1

The output of channels from snap info when one or more channels are closed is confusing. In the example below my intuition tells me that edge is forwarded to beta (so beta is carrying the same version as edge), not beta is forwarded to candidate. This is obviously not the intended interpretation.

I propose we change the upwards-arrow glyph to either a right-hand-upwards-arrow or a bottom-right-border as below. This will indicate more clearly that, in the example, beta is forwarded to candidate.

This decision should match the decision from Proposal to change the channels display of snapcraft status

CURRENT

channels:
  stable:    3.6                2019-06-16 (3059) 59MB classic
  candidate: 3.6                2019-06-15 (3059) 59MB classic
  beta:      ↑                                         
  edge:      3.6+git20.g7d0391d 2019-07-02 (3137) 59MB classic

Proposal 1

channels:
  stable:    3.6                2019-06-16 (3059) 59MB classic
  candidate: 3.6                2019-06-15 (3059) 59MB classic
  beta:      ⬏                                         
  edge:      3.6+git20.g7d0391d 2019-07-02 (3137) 59MB classic

Proposal 2

channels:
  stable:    3.6                2019-06-16 (3059) 59MB classic
  candidate: 3.6                2019-06-15 (3059) 59MB classic
  beta:      ┘                                         
  edge:      3.6+git20.g7d0391d 2019-07-02 (3137) 59MB classic

Proposal to change the channels display of snapcraft status
#2

in a number of situations snap falls back to using ASCII output. You can force this with --unicode=never. What would you do in this mode?


#3

If we need to use characters only in ASCII, then proposal 2 will still work I think?


#4

nope, that’s not ASCII


#5

What do we currently do in such situations? Oh I see, ↑ is actually in the ASCII set. Can we feature-detect and use the ANSI or Unicode set (Proposal 2 is definitely in ANSI, I’m not sure whether Proposal 1 is or if Unicode is required there) in most cases but revert to the ASCII ↑ when we can’t show the angled arrows?


#6

No, ↑ is not ASCII either. Use --unicode=never to see what we do…

Edit: ASCII != ANSI is a lot of things. Both glyphs you’re talking about are in the IBM codepage for the US of A, and in windows-1252, which most people don’t use when on Linux.


#7

ok, so we use the caret when in ASCII mode:

channels:
  stable:    3.6                2019-06-16 (3059) 59MB classic
  candidate: 3.6                2019-06-15 (3059) 59MB classic
  beta:      ^                                         
  edge:      3.6+git20.g7d0391d 2019-07-02 (3137) 59MB classic

How about adding a hyphen to that, which is a pattern I’ve seen on other projects in my distant memory:

channels:
  stable:    3.6                2019-06-16 (3059) 59MB classic
  candidate: 3.6                2019-06-15 (3059) 59MB classic
  beta:      -^                                         
  edge:      3.6+git20.g7d0391d 2019-07-02 (3137) 59MB classic

Alternatively we can just leave the ASCII output as-is.


#8

you realise this is what snapcraft is doing :slight_smile:


#9

Yes. I have proposed another change there to add-in the nice arrows to unify their output. We’ll obviously need to include the ASCII fallback there too, but I’d like to see a more meaningful output than just a caret on terminals that support it.