schollz / schollz/progressbar

When reducing terminal size, bar will not remain in the same line in each rendering. Is it a bug?

Open
#106 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
4.7k
Forks
258
Avg merge
13h 31m
Merged PRs (30d)
1

Description

  • Device: MacBook Pro 13-inch, 2020
  • Terminal: build-in Terminal application
  • Description:
    • After the width of terminal got thinner, the previous bar remain above (which is acceptable).
    • But the new bar kept starting new lines and re-render each progress, which may not be acceptable.
    • Please refer to attached screen capture file.

source test file content:

package progress

import (
	"os"
	"testing"
	"time"

	progressbar "github.com/schollz/progressbar/v3"
	. "github.com/smartystreets/goconvey/convey"
	"golang.org/x/term"
)

func TestGeneral(t *testing.T) {
	Convey("progressbar", t, func() { testProgressbar(t) })
}

func testProgressbar(t *testing.T) {
	bar := progressbar.Default(100, "test progressbar")

	for i := 0; i < 100; i++ {
		bar.Set(i)
		time.Sleep(50 * time.Millisecond)
	}

	bar.Clear()
	w, h, err := term.GetSize(int(os.Stdout.Fd()))
	So(err, ShouldBeNil)
	t.Logf("Done, terminal size: %d x %d", w, h)
}

https://user-images.githubusercontent.com/6083108/131773460-a44c00ec-7065-4d05-8d85-1ad95ab09146.mov

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the provided Go test, especially TestGeneral and testProgressbar, and reproduce the behavior in the macOS Terminal while narrowing the terminal width. Inspect the progress bar's rendering and terminal-size handling to determine whether each update should remain on one line after resizing. Done means the behavior is reproduced, clarified, and covered by a regression test.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.