You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
The tea.Printf command was added back in 2022 and is great, but I'm curious if the truncation of the output lines can be removed? There's a mention in the original issue by @meowgorithm of how to handle word wrapping and whether to give the user an option, but apparently the output was automatically truncated for some reason, but I'm not completely clear as to why that's a requirement. To me, if you're giving the user a way to print specifically outside of the rendering pipeline, then it shouldn't be truncated. But maybe I'm in the minority here.
The reason I ask is that I am using bubbletea to output an animated status message and some other useful information during a long-running application, and using tea.Println to output a form of "log" messages that should remain after the program ends, and not be cleared. Further, the user may need to copy/pasted the logs out of the terminal at times. I can wrap the output manually with lipgloss.Style, but then copying the output has extra newlines which muddy the output. If the log lines aren't wrapped at all, then the terminal wraps the lines like normal, and copy-pasting works normally, which is ideal for me.
I understand others may have differing opinions on this, so if the answer is just "no", then I understand. It just seems counterintuitive to me, so I thought I'd ask. Thanks! :)
Setup
OS: Arch Linux
Shell: zsh
Terminal Emulator: alacritty
Terminal Multiplexer: n/a
To Reproduce
Steps to reproduce the behavior:
Create a model.
Use tea.Printf/tea.Println commands to print a message longer than the width of the terminal.
Source Code
Something like
type Model struct {}
// ... other stuff ...
func (m Model) Update() (tea.Model, tea.Cmd) {
return m, tea.Println(strings.Repeat("A"*1000))
}
Expected behavior
The strings sent with tea.Printf and tea.Println are sent verbatim to the output without truncation.
The text was updated successfully, but these errors were encountered:
Ope! It looks like the most recent commit to the standard renderer (1a9ea44) actually fixes this already! That teaches me to only look at the associated PR and not the most recent branch. 🤣
Describe the bug
The
tea.Printf
command was added back in 2022 and is great, but I'm curious if the truncation of the output lines can be removed? There's a mention in the original issue by @meowgorithm of how to handle word wrapping and whether to give the user an option, but apparently the output was automatically truncated for some reason, but I'm not completely clear as to why that's a requirement. To me, if you're giving the user a way to print specifically outside of the rendering pipeline, then it shouldn't be truncated. But maybe I'm in the minority here.The reason I ask is that I am using bubbletea to output an animated status message and some other useful information during a long-running application, and using
tea.Println
to output a form of "log" messages that should remain after the program ends, and not be cleared. Further, the user may need to copy/pasted the logs out of the terminal at times. I can wrap the output manually withlipgloss.Style
, but then copying the output has extra newlines which muddy the output. If the log lines aren't wrapped at all, then the terminal wraps the lines like normal, and copy-pasting works normally, which is ideal for me.I understand others may have differing opinions on this, so if the answer is just "no", then I understand. It just seems counterintuitive to me, so I thought I'd ask. Thanks! :)
Setup
To Reproduce
Steps to reproduce the behavior:
tea.Printf
/tea.Println
commands to print a message longer than the width of the terminal.Source Code
Something like
Expected behavior
The strings sent with
tea.Printf
andtea.Println
are sent verbatim to the output without truncation.The text was updated successfully, but these errors were encountered: