Scrolling viewport issues

[mistakenelf]

I'm working on a scrolling viewport for a file manager im building. There is a cursor to keep the currently selected file/folder that you are on as you scroll through them. When you reach the top of the list, I want to push the viewport to the bottom and set the cursor to the length of files that are loaded. When you reach the bottom I reset the cursor to 0 and then set the viewport to GotoTop. This works perfect for lists that dont go outside the viewport, but, once the viewport needs to scroll, seems like the cursor does not keep in sync with the viewport.

I have the following function created to deal with viewport position and cursor position as you go up or down the file tree:

func (m *model) scrollViewport() {
	top := m.viewport.YOffset
	bottom := m.viewport.Height + m.viewport.YOffset - 1

	if m.cursor < top {
		m.viewport.LineUp(1)
	} else if m.cursor > bottom {
		m.viewport.LineDown(1)
	}

	if m.cursor > len(m.files)-1 {
		m.cursor = 0
		m.viewport.GotoTop()
	} else if m.cursor < 0 {
		m.cursor = len(m.files) - 1
		m.viewport.GotoBottom()
	}
}

When I scroll down past the bottom of the currently viewable View of the viewport and then select a folder to open I receive the following error:

Caught panic:

runtime error: slice bounds out of range [11:7]

Restoring terminal...

goroutine 1 [running]:
runtime/debug.Stack(0x57, 0x0, 0x0)
	/usr/local/go/src/runtime/debug/stack.go:24 +0x9f
runtime/debug.PrintStack()
	/usr/local/go/src/runtime/debug/stack.go:16 +0x25
github.com/charmbracelet/bubbletea.(*Program).Start.func2(0xc00016e880)
	/Users/knipferrc/git/fm/vendor/github.com/charmbracelet/bubbletea/tea.go:294 +0xd3
panic(0x12f0d00, 0xc0000b95d8)
	/usr/local/go/src/runtime/panic.go:965 +0x1b9
github.com/charmbracelet/bubbles/viewport.Model.visibleLines(...)
	/Users/knipferrc/git/fm/vendor/github.com/charmbracelet/bubbles/viewport/viewport.go:81
github.com/charmbracelet/bubbles/viewport.Model.View(0x8f, 0x27, 0xb, 0x0, 0x0, 0xc00017a2a0, 0x7, 0x7, 0x0, 0x0)
	/Users/knipferrc/git/fm/vendor/github.com/charmbracelet/bubbles/viewport/viewport.go:366 +0x254
main.model.View(0xc0004d5d00, 0x6, 0x8, 0x8f, 0x27, 0xb, 0x0, 0x0, 0xc00017a2a0, 0x7, ...)
	/Users/knipferrc/git/fm/src/view.go:18 +0x172
github.com/charmbracelet/bubbletea.(*Program).Start(0xc00016e880, 0x0, 0x0)
	/Users/knipferrc/git/fm/vendor/github.com/charmbracelet/bubbletea/tea.go:419 +0x72c
main.main()
	/Users/knipferrc/git/fm/src/main.go:41 +0x275

It's kind of hard to follow this, is there a way to get more info on where the error is coming from?

The rest of the logic lives in https://github.com/knipferrc/fm/blob/main/src/update.go

[meowgorithm]

Hi! So if I understand correctly, you want the cursor to just back to the top when you reach the bottom, and vice-versa, yes? If so, I'm not able to reproduce the panic on my end when the list is taller than the viewport. That is, it's working great.

The stack trace is probably the best way to figure out where the panic is happening as it's very specific, but you could also log to a file (Bubble Tea has the tea.LogToFile helper function for that), or debug with Delve.

Anyway, do let me know how to do reproduce. This could be a bug in the viewport component.

[mistakenelf]

Yeah exactly. If I’m at top and scroll up, I want it to jump to the bottom and vice versa. To reproduce, if you’re in a directory with a lot of files, for instance the home directory, if I’m at the top, scroll up to go to the bottom of the list, then try to open a directory down there, it will panic

[meowgorithm]

It sounds like you also need to reset viewport.Model.YOffset when changing directories — but we should be doing this automatically in viewport.Model.SetContent() to prevent panics. I'll submit a patch for this later tonight.

[meowgorithm]

Alrighty, if you bump Bubbles to the latest version (v0.7.8) your issue should vanish. We added a check to viewport.SetContent() to keep the y-offset in bounds.

---

On an unrelated note, I'd recommend doing your filesystem operations (i.e. filesystem.GetDirectoryListing) in a command since the filesystem operations will completely block until they're finished. This means your user can't quit or abort or do anything in the meantime. If they're browsing a laggy network drive, or accidentally opening a directory with a massive amount of files inside, they could be in for a hard time. Commands run asynchronously, and are a little more work, but worth it for something like this.

[mistakenelf]

Awesome, yep its working perfectly. Ahh ok, I will definitely move that into a command. Thanks for the tip and for the viewport fix, appreciate it!!