Hi Gisle, Please ensure you hit reply-to-all so that the thread continues on the mailing list
On Sat, May 3, 2014 at 12:59 PM, Gisle Vanem <[email protected]> wrote: > Would it not be a better idea to wrap this segment completely into a >>> >> if(opt.show_progress || opt.verbose) block? >> That way, the hurl is generated only if it is required. >> > > That's probably okay. I wasn't aware of '--no-verbose'. > > > I've also changed the conditional in the #ifdef WINDOWS section. >> According to your original patch, the console title is updated when the >> user invokes wget only with --no-verbose too. This is contrary to what I'd >> expect since the progress bar isn't displayed in that use case. If I >> understand correctly, you only want to update the console title when the >> progress bar is being displayed, we only need check opt.show_progress for >> that. Or did I miss something? >> > > I'm confused about all those options. My idea was to hide the > title-bar/progress > only when super-quiet. That should be with option '-q' alone (and '-b'). > Or? Show it in all > cases otherwise. > > But, far as I remember, the title-bar/progress was displayed only when in verbose mode. In other modes, such that -nv and -q, they weren't shown at all. I'm not sure what you're confused about. Also, I understand you want to hide them on -q, but -b? That is completely unrelated. To break this down, Wget has 4 verbosity modes: 1. Verbose (-v) 2. No-Verbose (-nv) 3. Quiet (-q) 4. No-Quiet (--no-quiet) Of these, --no-quiet doesn't work at all and is similar to -v. This, IMO, is a bug, but a topic for another discussion. Among the three verbosity modes, the progress bar and hence the progress status in the Windows console title are displayed ONLY in the verbose mode by default. The quiet mode prints nothing, apart from severe errors by default. The no-verbose mode is almost like the quiet mode with an extra line printed per file. With my original patch, we add the --show-progress option which forces displaying the progress bar in any verbosity mode. Now, the patch you submitted earlier, puts the follwoing conditional: opt.show_progress || !opt.quiet This imples that the condition is true if we either want to display the progress bar, OR are not in quiet mode. But Not in quiet mode means, we could be in no-verbose mode. Here, by default the progress bar is not shown. The condition evaluates to true, and hence the windows console title will be updated with the progress information despite the fact that a progress bar isn't being shown. What, you really want to do is that the console title is updated with the progress information if and only if the progress bar is also shown on screen. Let me know if there's any more confusion. > > >> And the most important diff: >> >>> >>> diff -Hb -u3 ../Git-latest/src/retr.c ./retr.c >>> --- ../Git-latest/src/retr.c 2014-05-01 14:54:39 +0000 >>> +++ ./retr.c 2014-05-01 15:54:30 +0000 >>> @@ -412,7 +412,7 @@ >>> if (progress) >>> progress_update (progress, ret, ptimer_read (timer)); >>> #ifdef WINDOWS >>> - if (toread > 0 && opt.show_progress) >>> + if (toread > 0 && (opt.show_progress || !opt.quiet)) >>> >>> ws_percenttitle (100.0 * >>> (startpos + sum_read) / (startpos + toread)); >>> #endif >>> >>> ----------- >>> >>> As you see, my local files are not under Git-control. So it's hard for me >>> to >>> give you any "git diff" patches. And since I suspect src/Changelog is >>> created from a mysterious git-command, I don't know how you want a >>> change-entry from me. The 'git-format-patch' won't work here. But here >>> is a >>> suggestion: >>> >>> 2014-05-01 Gisle Vanem <[email protected]> >>> >>> * ftp.c (ftp_loop_internal): Call url_string() to retrieve a 'hurl' >>> incase WINDOWS >>> needs to set the console-title. >>> * http.c (http_loop): Call url_string() to retrieve a 'hurl' incase >>> WINDOWS >>> needs to set the console-title. >>> * retr.c (fd_read_body): Update the read-percentage for WINDOWS if >>> '--show-progress' or NOT '--quiet' are set. >>> >>> But hopefully you get the idea. >>> >>> >>> Please do check the attached patch. It should fix the erroneous empty >>> >>>> lines you reported. >>>> >>>> >>> Looks fine now. >>> >>> --gv >>> >>> >> >> >> -- >> Thanking You, >> Darshit Shah >> >> -- Thanking You, Darshit Shah
