charmbracelet/bubbletea

Unmanaged Output Truncation (e.g. `tea.Println`)

calebstewart opened this issue · 1 comments

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:

  1. Create a model.
  2. 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.

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. 🤣