viewport horizontal (left/right) scroll

[tty2]

Is there any common way to have left/right scroll for viewport (or any other component)?

I'm working on the project that should show logs from a container.
If I set width == right corner of a terminal, I'll get long lines with line breaks (first screenshot).
As a result I can't use viewport.ScrollPercent cause it relies on number of lines and I lose some lines in the end.

Plus, for data like logs it's more convenient to have similar appearance (compare screenshots). But the problem of second way that I lose the end of the lines. Can I use second way and scroll left/right somehow?

[meowgorithm]

Those are valid points. There's no way to do this currently, so I'm going to convert this into an issue so we can track it accordingly. viewport should have this functionality.

[tty2]

Thanks @meowgorithm

About implementation:
Currently I have only one idea how to implement it:

• pop n first runes from strings list on move right;
• push n runes back to the start of every string in the list on move left;

But this approach consumes memory. We have to keep initial list of lines and cut lines.
WDYT?
If it looks as a valid solution I can try to implement it.

[plungingChode]

Hi!
I just came across this issue myself. I tried @tty2 's method, but this only works if the displayed strings aren't formatted using ANSI escape sequences. If they are, it breaks them up and exposes the normally invisible characters in the sequence.

My idea was to treat ANSI escapes as a single unit, keep track of them in a custom struct and slice strings based on the length their printable text content, rather than rune width or byte size.

type AnsiString struct {
	s      string
	widths []int
	// TODO should be a bitfield
	escapeLocations map[int]struct{}
}

This way something like this is possible:

s :=  "\x1b[1mText\x1b[0m"
as := ansistring.New(s)
sliced := as.SlicePrintable(2, as.PrintableRuneWidth())
fmt.Println(sliced) // \x1b[1mxt\x1b[0m

This of course requires a lot of extra memory and doesn't result in strings with a deterministic length: currently, the escape sequences are always included in the slice, so as not to break styling.

Do you think this could be a solution to this issue? Either way, I'll share my implementation once I've cleaned it up for reference.

[Sojamann]

I stumbled onto this topic myself this weekend (coming from gum). I had a similar idea at at the beginning but there are a few things to to keep in mind:

• is this not almost a reverse lipgloss / lipgloss style parser?
• all these ansi codes especially the colors are complex ... https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797 making an implementation potentially error prone
• one does not have to parse / read the ansi codes of the entire string, but only to the offset of where you want to cut
• can one not just store all, up to the cutting point, seen ansi sequences ... cut the real string ... prepend the ansi sequences to the remaining string