Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the extra space, and make the wide element fill the whole term… #350

Merged
merged 2 commits into from
Jan 25, 2022

Conversation

sigmaSd
Copy link
Contributor

@sigmaSd sigmaSd commented Jan 10, 2022

…inal width

fix #348
fix #342 again

Recap of the situation:

If no wide elements is used, any printing after will happen on the same line as the progress bar, this might be not what users expects but I think its a desirable change, and reverting to the old behavior is a simple as adding println!() after the progress bar

@djc
Copy link
Member

djc commented Jan 11, 2022

What happens if there is no wide element?

@sigmaSd
Copy link
Contributor Author

sigmaSd commented Jan 11, 2022

if there is no wide element,

  • the bar wont fill the terminal width
  • there is no ending new line

The next prints will be on the same line

@djc
Copy link
Member

djc commented Jan 14, 2022

if there is no wide element,

* the bar wont fill the terminal width
* there is no ending new line

The next prints will be on the same line

So that doesn't sound like what we want. Maybe in absence of a wide element maybe we should have a sort of virtual wide element that fills the line up with spaces?

@sigmaSd
Copy link
Contributor Author

sigmaSd commented Jan 14, 2022

I personaly prefer to leave that to the user

What If I actually want to print on the same line, cool that just works

What if I want the old behaivour and print on the next line, simple add println!() and then print what I actually want

Other ideas I thought about is println!() on Progressbar drop but that gets not easy when considering multi progressbar, thats why I adovocate the above for its simplicity

@sigmaSd
Copy link
Contributor Author

sigmaSd commented Jan 14, 2022

I guess the virtual space is also possible but it means that the cursor will always be locked to the right edge of the terminal, which might also look weird

@djc
Copy link
Member

djc commented Jan 17, 2022

Isn't that what it already looks like if we have a wide element today (or after this PR)?

@sigmaSd
Copy link
Contributor Author

sigmaSd commented Jan 18, 2022

I mean if there is no wide element:

  • on master branch, the cursor ia one space away from the bar
  • with this pr, the cursor is at the end of the bar
  • with the idea of virtual space, the cursor is always at the right terminal end no matter the width of the bar

Wide elemnts actually hide these differences since they fill the entire width

@djc
Copy link
Member

djc commented Jan 23, 2022

The question is how this compares to the situation pre-#338. It seems to me that pre-#338, the cursor always ended up in the first column of the line after the progress bar. IMO changing that to have the cursor consistenly in the last column of the progress bar line seems the best approach. I don't see much virtue in having the cursor be directly after the bar if the bar is non-wide.

@sigmaSd
Copy link
Contributor Author

sigmaSd commented Jan 24, 2022

That's reasonable, I added a commit with your suggestion.

@djc djc merged commit af3bd31 into console-rs:main Jan 25, 2022
@djc
Copy link
Member

djc commented Jan 25, 2022

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Why is there an additional space in the end? A newline character should be printed after completion
2 participants