Delta456
[BUG] long text fails to wrap
Describe the bug Text lines that are longer than terminal width fail to wrap inside the box
To Reproduce You can reproduce the behaviour by simply creating a string that is longer than terminal width: notice that you can retrieve the current terminal length with
import (
"golang.org/x/term"
)
width, _, err := term.GetSize(0)
if err != nil {
return
}
and replicate a string of given width.
Then simply
Box.Print("title", long_string)
produces effects like this.
Expected behavior The box wraps text automatically. Ideally the user can specify wrap after a certain length.
Workaround At the moment I am making use of go-wordwrap to wrap the text myself before feeding it into the box.
import (
"github.com/mitchellh/go-wordwrap"
)
Box.Print("title", wordwrap.WrapString(sb.String(), uint((2*width)/3)))
Versions (please complete the following information, if relevant):
Machine: MacBookPro15,2
Kernel: Darwin 21.2.0
OS macOS 12.1.0 Monterey
Terminal iTerm2 (Version 3.4.14)
Shell /bin/zsh
Hmm I am thinking of making a flag like AllowWrapping when set to true will allow wrapping of lines else the lines won't be wrapped. I also would like to know if I should also let the user provide the number or uint((2*width)/3)) should be used instead?
I am thinking of making a flag like AllowWrapping when set to true will allow wrapping of lines
Yes, this sounds like the best solution.
if I should also let the user provide the number or
uint((2*width)/3))should be used instead?
another idea could be, instead of AllowWrapping = true/false, to have a numerical parameter, say WrappingWidth = 0,...,1 between 0 and 1 that directly specifies the size to wrap at, with 1 meaning "no wrap" or so. Which begs the question: is there any use case where users do not want to wrap text? I cannot imagine any scenario where users may want to leave the text pending off terminal width 🤔
In any case this probably depends on the implementation complexity and I would be happy already to have a boolean parameter that allows wrapping at a fixed length by default, just to avoid the boxes to be messed up in some cases.
By the way, just for reference, this is the project I am working on and here is where I am invoking your library.
In some scenarios people may want to pad according to their own needs so I think I will let the user allow it. By default it would be uint((width*2)/3).
What you think about this? 🤔
Also it looks like you are using a very old version of the library. v2.2.2 is the latest version.
After several testing, I will be using muesli/reflow instead of go-wordwrap because the former also has support for CJK, tabs and emojis and it provides several options.
In some scenarios people may want to pad according to their own needs so I think I will let the user allow it. By default it would be
uint((width*2)/3).What you think about this? 🤔
Also it looks like you are using a very old version of the library.
v2.2.2is the latest version.
Please what you think about this
In some scenarios people may want to pad according to their own needs so I think I will let the user allow it.
yes, I agree that giving the user more flexibility may help in many cases. Moreover 2/3 is also a good default!
Also it looks like you are using a very old version of the library. v2.2.2 is the latest version
oooops, I just noticed it too. I will update the modules! What are the main differences (or do you have a page with new release notes I can read)?
oooops, I just noticed it too. I will update the modules! What are the main differences (or do you have a page with new release notes I can read)?
Yes, it is here.
Heads up. I have implemented this feature in this commit https://github.com/Delta456/box-cli-maker/pull/22/commits/d7a6d036685c0736876fb03222984296dc87dde7 you can read how the future API would be.