Duplicate rendering of extra empty lines

[zc2638]

When revert 3e6b9bf
Each time the progress bar is rendered, an empty line is added.

func main() {
	bar := progressbar.Default(100)
	for i := 0; i < 100; i++ {
		bar.Add(1)
		time.Sleep(40 * time.Millisecond)
	}
}

[zc2638]

@schollz

[schollz]

3e6b9bf didn't fix any particular problem I knew of and caused a new problem - that progressbars that are shorter than previous are not be cleared so you get things like [0s:3s]s] at the end...

but now I see you have a particular problem that you were trying to fix. I think the fix for that problem you are having is related to the calculation of the window width used with the Default function. Can you try reducing the width here: https://github.com/schollz/progressbar/blob/master/progressbar.go#L679-L688

Also, what system are you seeing this (terminal, shell, OS, etc.)?

[zc2638]

I found that the default progress bar symbol width is uncontrollable. Apart from replacing it, how to solve it?

[schollz]

See my previous comment

[zc2638]

I haven't found a way to calculate the width of █ symbol. Do you have any good solution？

When I set it like this, the performance is normal:

progressbar.OptionSetTheme(progressbar.Theme{
	Saucer:        "=",
	SaucerPadding: " ",
	BarStart:      "|",
	BarEnd:        "|",
	SaucerHead:    ">",
})

[axetroy]

I also encountered this problem on macOS with version v3.8.3

[reber0]

macOS, v3.8.3, same problem

[Lan-ce-lot]

macOS, v3.13.0, same problem

[JohnieXu]

The same problem on Window10 powershell with version v3.13.1

[tukaelu]

@schollz
I too am having trouble with this issue.
Is it correct to say that the reason for reverting 3e6b9bf is the issue where a display like [0s:3s] shown at the end of the progress bar during execution remains even after execution?

If that is correct, it seems to me that you probably have a terminal that is not working correctly because the current implementation keeps increasing s.maxLineWidth, which embeds extra space.

progressbar/progressbar.go

Line 990 in 3d12297

str := fmt.Sprintf("\r%s\r", strings.Repeat(" ", s.maxLineWidth))

I think that filling in the terminal with white space for the width of the terminal would solve all problems.

I created a pull request that deals with this issue.
As far as I can tell from the examples/basic code, it doesn't seem to reproduce the problem, but please check just in case.

[tukaelu]

I found an error in the correction, so I withdrew the pull request(#168).
I finally understood that the cause of this issue lies in the part that counts the width of the █ symbol.

I made a fix to keep the s.maxLineWidth variable fixed at the terminal width, as I had observed it increasing as the progress bar advanced. However, it was not the correct approach.

When I set the C value for the LANG environment variable and ran it, s.maxLineWidth continued to return a fixed value. However, when I changed it to my usual setting, ja_JP.UTF-8, the issue of continuous line breaks reappeared.

This seems to be caused by the current implementation counting the number of runes.

Currently, since the library update for mattn/go-runewidth, which we use for calculating the width of runes, is lagging behind, it seems that the issue can be resolved by replacing it with rivo/uniseg that it internally uses.

[tukaelu]

@zc2638 @axetroy @reber0 @Lan-ce-lot @JohnieXu

I apologize for mentioning many of you.
The PR #169 that resolves this issue has been merged, and it has been released as v3.14.0.

I believe this problem has likely been resolved, so please everyone check it out.

[Lan-ce-lot]

@zc2638 @axetroy @reber0 @Lan-ce-lot @JohnieXu

I apologize for mentioning many of you. The PR #169 that resolves this issue has been merged, and it has been released as v3.14.0.

I believe this problem has likely been resolved, so please everyone check it out.

I'm glad to hear that.👍