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
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?
If we need to use characters only in ASCII, then proposal 2 will still work I think?
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?
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.
1 Like
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.
1 Like
you realise this is what snapcraft is doing ![:slight_smile: :slight_smile:](https://forum.snapcraft.io/images/emoji/twitter/slight_smile.png?v=12)
1 Like
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.
IMHO, proposal 1 when we have unicode looks better so I proposed https://github.com/snapcore/snapd/pull/9176 during my lunch break ![:smile: :smile:](https://forum.snapcraft.io/images/emoji/twitter/smile.png?v=12)
EDIT: nvm we can’t have nice things because unicode is hard so I closed that PR, perhaps someday we can haz nice things