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

text rendering incorrectly using serial data #931

Open
Horryportier opened this issue Feb 21, 2024 · 7 comments
Open

text rendering incorrectly using serial data #931

Horryportier opened this issue Feb 21, 2024 · 7 comments

Comments

@Horryportier
Copy link

Describe the bug
text dose not render correctly when inserting longer line

Setup
Please complete the following information along with version numbers, if applicable.

  • OS [e.g. Pop OS]
  • Shell [e.g. bash]
  • Terminal Emulator [e.g. wezterm]
  • Terminal Multiplexer [e.g. wezterm workspaces ]

To Reproduce
i have text value that i append to data from serial port and its displayed

Source Code
https://github.com/Horryportier/go-serial-tui/blob/main/main.go

Expected behavior
content should not disappear whenever longer line is append. from my test's when not using data from serial it works without any issues

Screenshots
https://github.com/charmbracelet/bubbletea/assets/42907709/f60e8030-80da-46a3-bd8e-7f7bead8d006

@muesli
Copy link
Member

muesli commented Mar 1, 2024

You need to wrap your content at the given maximum width.

@Horryportier
Copy link
Author

#43 looked at this issue and added wrapping using github.com/muesli/reflow/wordwrap package yet it still has that weird despairing bug although text appears when i add long enough string so wordwrap triggers and then all seems to stay on screen from that point on

@m1cm1c
Copy link

m1cm1c commented Mar 11, 2024

#43 looked at this issue and added wrapping using github.com/muesli/reflow/wordwrap package yet it still has that weird despairing bug although text appears when i add long enough string so wordwrap triggers and then all seems to stay on screen from that point on

I'm experiencing this exact bug. I thought about calling

import (
	"github.com/inancgumus/screen"
)

func clearScreen() {
	screen.Clear()
	screen.MoveTopLeft()
}

in the beginning of View() but https://pkg.go.dev/github.com/charmbracelet/bubbletea#ClearScreen states: "Note that it should never be necessary to call ClearScreen() for regular redraws." So I think there must be a better way to fix this. Did you figure something out by now?

@meowgorithm
Copy link
Member

Hi! @Horryportier or @m1cm1c: can you produce a minimal example, with reflow, that reproduces the issue? That will help us solve this quickly and effectively. If the bug you're seeing is in reflow itself, let's close this issue and open an issue there.

@Horryportier
Copy link
Author

I don't thing reflowis the issue, bug was present before I've added that library. Wordwrap solved issue partially because it still would occurred for strings shorter that wrap threshold but it would fix itself after wordwrap was triggered

As for reproducing the bug it would hard because it only occurs for me when dealing with text data from serial port. So there might be issue with data send from esp32 having some weird glyphs. Although arduino ide 2 works just fine.

@m1cm1c
Copy link

m1cm1c commented Mar 14, 2024

@meowgorithm Here is a fairly small program that reliably reproduces the described behavior: https://gist.github.com/m1cm1c/0248ef748db56d0cc1f7e4398a3f2fad

I ran it via: go run .

Initial state (looks fine):
image

After making the window wider (looks fine):
image

After making the window narrower again, "(esc to quit)" repeats:
image

OS: Manjaro
Go version: 1.21.7
Architecture: AMD64
Terminal: xfce4-terminal (version 1.1.3)
Shell: GNU bash (version 5.2.26(1))

@Horryportier
Copy link
Author

that looks like different bug than mine mine makes first few characters disappear corresponding to amount of additional text
image
image
image

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

No branches or pull requests

4 participants