Unintelligible console output #8812

Open
williamboman opened this Issue Jul 3, 2015 · 23 comments

Projects

None yet

6 participants

@williamboman

When running $ npm install on npm@3.1.0 node@0.12.5 the console output is pretty unintelligible.

Somewhat related to #8761. This issue doesn't only refer to the carriage return/new line issue but the look/behaviour of spinner and progress bar and the clipping of overflowing text that prepends the loading bar.

  • Text overflow issues when resizing terminal window - iarna/gauge#3
  • Clipping of text prepending the progress bar (allocate more size for text, or separate text and progress bar with \n?)
  • Loading spinner looks unfinished
@iarna
Member
iarna commented Jul 4, 2015

Yes, if you change your window size while it's running it will mess it up. Uh... don't do that?

Yeah, we can try to catch SIGWINCH and look at the terminal size again although that's not universally available, so.

@iarna iarna added this to the 3.x milestone Jul 4, 2015
@iarna iarna added the support label Jul 4, 2015
@williamboman

@iarna This behaviour is also present when working with split panes, which I do constantly. It's so malfunctioning I have to change the way I work in the terminal (with npm install/update). No other package manager makes me have to do that. I really think it should be addressed (SIGWINCH would be nice, e.g. wget listens to it).

I also think the loading spinner (I think it is one) looks really weird, I prefer the old slash spinner. But that's just a personal preference 😄 .

@iarna
Member
iarna commented Jul 4, 2015

Hmm, I use split panes all the time and I've never encountered an issue… something somewhere must be misreporting the terminal size on you. Hmm…

@williamboman

@iarna Oh, no issues with terminal sizing per se. It's just that I like to work in other panes (often creating new ones horizontally) while an installation is ongoing (on top of installations on npm@3 being much slower - and I often do pretty big ones). Listening to SIGWINCH and resizing the progress bar accordingly would fix this.

What's the status on the progress bar? Is it a WIP or is it considered pretty much done?

@iarna
Member
iarna commented Jul 5, 2015

Pretty much done. The module providing the progress bar visuals is here:

https://github.com/iarna/gauge

At some point, I intend to make a meta-gauge library that exposes that API but allows plugging w/ a host of different progress indicators. That will probably happen when we start looking at making npm more embedable. (Specifically, one of those views would be to just print out progress updates in a parsable format to allow things calling npm (like Visual Studio) to display their own progress bars based on those updates.)

@iarna
Member
iarna commented Jul 5, 2015

Completion tracking is a separate concern and is isolated to https://github.com/iarna/are-we-there-yet, which has its top level change event trigger gauge show calls.

npmlog triggers pulse calls with every log line.

@iarna iarna added a commit that referenced this issue Jul 7, 2015
@iarna iarna gauge@1.2.1
PR-URL: iarna/gauge#3

Fixes: #8812
a78f81a
@iarna iarna modified the milestone: 3.2.0, 3.x, 3.2.1 Jul 7, 2015
@iarna
Member
iarna commented Jul 7, 2015

The "listen to column changes" fix is in, though some cruft still shows up, so I'm going to defer calling this fixed until we get that cleaned up.

@williamboman

The "cruft" is pretty much unavoidable afaik. Perfectly acceptable imo.

@iarna
Member
iarna commented Jul 7, 2015

Some of it I think I can fix 😁(Probably not when you shrink of course, but it shouldn't cruft up when you grow.)

@iarna
Member
iarna commented Jul 8, 2015

Yeah, plus clearing to the end of the line.

@iarna
Member
iarna commented Jul 8, 2015

I ended up going with iarna/gauge@ca15696 which just does a hide/show if we're already showing it. I can grow the window without any cruft.

@shreeve
shreeve commented Jul 9, 2015

Random comments about the gauge/bar. When used with npm 3, it takes a huge portion of the horizontal width (maybe 75%), leaving only a small amount for the actual text. It seems it should be the other way around. The user seems to want to know "where they are" in the process, but that can be accomplished with a friendly little bar and more space allotted to the text. As it is now, the text has so little room that it's become sort of useless. Also, the "end caps" seem unnecessary. Other improvements seem great.

@shreeve
shreeve commented Jul 9, 2015

Possibly a little cleaner look... a change in the order of the output and the following unicode tweaks:

ProgressBar.unicode = {
  startgroup: " ",
  endgroup: " ",
  complete: "",
  incomplete: "-",
  spinner: "◐◓◑◒",
  subsection: ""
}

npm-bar

@iarna
Member
iarna commented Jul 9, 2015

I don't believe that unicode is available on windows... (I originally had a similar variation on that)

@shreeve
shreeve commented Jul 9, 2015

@iarna - It's more than just the leading spinner... It's a few changes:

  • remove the startgroup and endgroup characters (they detract from, not enhance, the output)
  • replace the incomplete "shaded block" with a simple dash (it's nice to be able to "count", which is hard when chars run together)
  • move the progress bar to the left side, so everything lines up cleanly and is more consistent
  • make the progress bar more manageable (ie - 10 chars makes each tick 10%); having a huge bar with fine-grained percentages is too pedantic
  • move the "text" portion to the right of the bar, so you have plenty of room to output values instead of squeezing 'em before the bar
  • replace the spinner chars with something that is more consistent (each char the same size, etc.); the original blocks were totally inconsistent
@iarna
Member
iarna commented Jul 9, 2015

@shreeve I know, but that was the only thing that was actually a no-go, so it's what I called out.

The rest requires greater discussion because it comes down to aesthetics and different needs. I want the progress bar to actually move, even on people's absurdly large, 8000 module projects.

@iarna
Member
iarna commented Jul 9, 2015

I originally used characters from the same block as the one's you picked, but Windows commandline limitations are pretty heavy here. In a perfect world I'd use clock emoji for that. (You can have as many characters in a spinner as you like. It just happened that the examples were cycles of 4.)

@iarna
Member
iarna commented Jul 9, 2015

Hey, could you open a new issue with just your suggested changes in it? (I like to separate "I'm having a problem..." from "here's a potential solution" in terms of open issues– makes it easier to manage.)

@iarna
Member
iarna commented Jul 13, 2015

@williamboman You mention the "carriage return/newline issue" in your summary but… it's not clear to me what you're referring to?

@williamboman

@iarna Basically how it would not adjust to window size changes (fixed in iarna/gauge#3).

Feel free to rename the issue title as you wish if you wanna keep the issue open btw 😄

@iarna
Member
iarna commented Jul 17, 2015

Ok, so my plan now is:

  • Landing the improved resize handling (happening 7/17)
  • Add support for configuring the theme & spinner via the npm config, which will make it a lot easier to experiment with different layouts.
@iarna iarna added a commit that referenced this issue Jul 17, 2015
@iarna iarna gauge@1.2.2
This improves the progress bar display by doing our best to clean up if
someone changes the terminal size on us while we're updating things.
It's not perfect (it can't be perfect) but it's as good as we'll get
right now.

Improves: #8812
5656baa
@iarna iarna modified the milestone: 3.x-next, 3.1.3, 3.x Jul 20, 2015
@iarna iarna added bug already-triaged ux and removed support labels Oct 28, 2015
@fresheneesz

This seems related: #10469

@shellscape

@shreeve holy smokes I love that spinner gif

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment