More elegant spinner

[gillesdemey]

Would you be open to changing the default unicode theme to a more elegant spinner, like https://github.com/sindresorhus/elegant-spinner? The current implementation feels a bit crooked.

I'm not suggesting to introduce it as a dependency, as that would probably be too much effort.

[iarna]

elegant-spinner looks lovely, but I don't believe the brail blocks it uses are available across our supported environments. I looked at using them myself when I was first selecting characters for the spinner. (We already have an outstanding issue just for the darn solid block █), which is in the "is it double width? who knows" unicode classification, which means some settings can break everything. =/ Even just here on github, it's single-width in the fixed width font and double-width with the proportional font.

I kind of like the blobbyness of the current spinner, but I'm totally open to a replacement. What a replacement needs to do is, display correctly by default in the following environments:

• Windows cmd
• Windows powershell
• Windows gitbash
• Ubuntu Terminal
• Mac Terminal
• Mac iTerm2
• and ideally, Mac iTerm2 with "Treat ambiguous-width characters as double width" enabled

[iarna]

On my mind, btw, is a gauge@2 with better templating. At the same time it might be handy to have more than "unicode" and "ascii" for detected template types, so we can have more expressive characters on OSes that support it.

[dbkaplun]

I just found cli-spinner which looks great. I think a few of them should work everywhere.

[iarna]

I'm aware of it– and unfortunately IIRC, the answer is "almost none of them".

I'm not taking anything without actually testing them on all of the platforms listed.

Or... I actually took ALL of the unicode line drawing-ish characters and tried them on all of those platforms and had prepared a list of the one's that work. Unfortunately I seem to have been all cute and only recorded them in a tweet, finding it will take longer.

[iarna]

Found it! Ok, so this is (I believe) a complete list of characters that work across platforms:

←↑↓↔↕─│┌┐└┘├┬┼═║╒╓╔╕╖╗╘╙╚╛╜╝╞╟╠╡╢╣╤╥╦╧╨╩╪╫╬▀▄▌▐░▒▓■▬▲►▼◄◊○◘◙

Any spinner has to come from these or from the Unicode "basic latin" set.

[iarna]

You'll note annoyances, like the fat arrows are thinner sideways than up and down. Also that there's no rightward version of ← (I mean, there is →, but it's not supported on all platforms).

[iarna]

The original version of this module used ◐◓◑◒, which I think looks pretty keen but does not work everywhere. =/

Of those example spinners the following can work:

1. |/-\
2. ┤┘┴└├┌┬┐
3. .oO°Oo. (maybe, untested)
4. .oO@*

The first is the ascii spinner we already have. And I think 3 + 4 are pretty ugly =/

I'm be curious about seeing 2 in motion.

[gillesdemey]

I don't think the "ambiguous-width characters" option is supported as of yet? At least with the latest version of NPM and iTerm2.

[gillesdemey]

At the same time it might be handy to have more than "unicode" and "ascii" for detected template types

The Windows shell uses the CP437 character encoding, so that could be another type? (https://en.wikipedia.org/wiki/Code_page_437)

We could show the elegant spinner for full Unicode supported shells, the current unicode template for CP437 Windows shells and the ASCII template for non-unicode shells.

I'll play around for a bit with my own fork of Gauge to look into extending the character encoding detection.

EDIT: Testing this indicates that CP437 is more commonly the default character set.

[gillesdemey]

I've taken the liberty of testing some of my changes on the platforms that are available to me right now using three different themes:

• cp437
• unicode
• ascii

I've created an album to showcase all of the different rendering possibilities http://imgur.com/a/5UcqW

So far, my tests include:

Terminal and iTerm on OSX — mostly using zshell and some with bash to show that the shell isn't really influencing the rendering

cmd and the Git cmd on Windows, using whatever the default settings are for both.

I'll do some more tests on Linux and in Windows (Powershell mainly) when I have some more time on my hands.

[iarna]

When I last tried on Linux (Ubuntu), the brail code blocks weren't available in the default terminal fonts, but time does march on.

[iarna]

Ultimately I do think the fix for this is to allow templates to be specified not just for unicode and ascii, but for different OSes too, so Unicode + Mac can make use of everything, and the others can get a cut down version appropriate to their character sets.

[gillesdemey]

I've looked around for some modules that detect the available character set, but no luck. I'm also going off of the assumption that Windows only supports cp437 — even though it can support the full unicode range if it's set up properly.

[iarna]

I don't think the "ambiguous-width characters" option is supported as of yet? At least with the latest version of NPM and iTerm2.

I'm not sure what you mean? My understanding is that making "ambiguous-width characters" be double spaced currently breaks everything, because the solid block character is rendered as two spaces.

[iarna]

(Yeah, even determining unicode is a pain, let alone font character availability.)

[gillesdemey]

Re: ambiguous-width characters this is the behaviour I'm seeing, could totally be blamed on my iTerm nightly build though.

[iarna]

That looks like what I'd expect from it, yeah. =/

[gillesdemey]

I've updated the album to include Powershell on Windows and Terminal and XTerm on Ubuntu 14.04 LTS.

I'm not sure how far back we want to support Ubuntu, maybe this particular issue warrants taking a look at some older distros?

[othiym23]

So, as npm/npm#10648 points out, we don't really have control over what codepage Windows users are using. I've seen enough other issues from people using npm in a CJKV environment to lead me to believe that we probably need to only use characters that are guaranteed to be the same (half) width, regardless of codepage or encoding.

[gillesdemey]

I'd like to pick up where I left off at this issue. I'll run some tests using other code pages on Windows.

Should we consider going full ASCII for Windows machines? I'm assuming Windows is the only platform where multi-lingual support is problematic?

[iarna]

Yeah, I'm of the opinion we should go full ASCII on windows, and let users via configuration select a prettier display if that's what they want.

[gillesdemey]

Regarding full-width characters, this is what Wikipedia has to say:

Range U+FF01–FF5E reproduces the characters of ASCII 21 to 7E as fullwidth forms, that is, a fixed width form used in CJK computing.

So we can typeset those characters properly in CJK text. The output looks to be correct after changing my system language and switching to a CJK code page.

Any ideas on how the user might configure a different spinner, does such an option already exist?

[iarna]

It's not double width characters per se that are the concern. It's ambiguous width characters, that some terminals treat as double width and some treat as single width. Without knowing how wide the character will be displayed as, there's no way to correctly layout a line.

[gillesdemey]

Correct, but as long as we stay within the ASCII range, we can assume that every terminal will treat it as either half-width for non-East-Asian character sets and full-width for East-Asian character sets.

[iarna]

If we stay in the ASCII range we can assume every terminal will treat all of that as half width. East Asian code pages have a different set of codepoints for full width characters.

You'll note in your example above that everything is half width except the arrow.

[iarna]

As I said earlier, my intent for fixing this is:

Ultimately I do think the fix for this is to allow templates to be specified not just for unicode and ascii, but for different OSes too, so Unicode + Mac can make use of everything, and the others can get a cut down version appropriate to their character sets.

So specifically, for Windows it'll get ASCII as we have no way of determining support, Linux will get something closer to what we have today, and Mac can have a much richer result.

I have a rewrite in process that I'll be ready to share with you all in the next week or two, probably.

[iarna]

I've done a little research into how to support windows and it means either a system call, which is out due to it requiring C, or a call out to a command line tool, which might be the right answer for some applications but is, I think, out of scope for gauge.

[iarna]

My in progress branch (with lots of unsquashed wip commits) is here: https://github.com/iarna/gauge/tree/new-rewrite

[iarna]

@gillesdemey @dbkaplun

So this work has landed in master and is out as gauge@2 with a beta tag– you can install it by explicitly asking for the version or installing gauge@beta.

Now is the time for figuring this out! It can select different themes based on your OS, so OSX users can get a much richer set of unicode.

Please join me in the bikeshedding issue to hash things out:

https://github.com/iarna/gauge/issues/36

(I'm closing this issue in favor of that one.)