explore panics in debug mode
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 40.5k
- Forks
- 2.3k
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 85
Description
Describe the bug
explore panics when scrolled past the end
How to reproduce
- run
$env | explore - Keep using PageDown till it stops scrolling
- Pres the down arrow
Expected behavior
Do nothing (already viewing the end of table)
Screenshots
× Main thread panicked.
├─▶ at crates/nu-explore/src/views/record/mod.rs:697:5
╰─▶ 77 76
help: set the `RUST_BACKTRACE=1` environment variable to display a backtrace.
This is on
fn get_percentage(value: usize, max: usize) -> usize {
debug_assert!(value <= max, "{value:?} {max:?}");
Configuration
| key | value |
|---|---|
| version | 0.96.2 |
| major | 0 |
| minor | 96 |
| patch | 2 |
| branch | |
| commit_hash | |
| build_os | linux-x86_64 |
| build_target | x86_64-unknown-linux-gnu |
| rust_version | rustc 1.78.0 (9b00956e5 2024-04-29) |
| rust_channel | 1.78.0-x86_64-unknown-linux-gnu |
| cargo_version | cargo 1.78.0 (54d8815d0 2024-03-26) |
| build_time | 2024-08-03 20:14:38 -07:00 |
| build_rust_channel | debug |
| allocator | mimalloc |
| features | default, sqlite, system-clipboard, trash |
| installed_plugins |
Additional context
The problem seems to be WindowCursor manages both "view" and a "window" that sometimes seems to be assumed to fit within the view. But sometimes it isn't clamped on update and this seems to trigger the debug_assert.
I was looking at fixing, but realized the current design is a bit unhandy:
- WindowCursor has view and window fields
- But the view field really defines the view size and window position
- While the window field defines the window size and cursor position within the window
- So if you want to move the window, you update the view field!
- We need to maintain the invariant that the window always fits within the view (so that the cursor can't move past data)
- With the current design it's lossy - you can keep clamping the window due to operations on WindowCursor, but you lose the original size and so can't reliably "unclamp" it on reverse operations
- In practice it kind of works because the drawing code happens to reset window sizes - but it still feels unnatural it's needed, could lead to issues in the future and might already be a problem (if the reset happens too early/too late); not sure
- Alternatively, we could "merge" Cursor into WindowCursor so that we can preserve the window size information (while reporting the clamped value via the public API). With Cursor being a separate thing, many methods don't have enough information to do that.
Any thoughts about getting rid of Cursor as a separate entity so that we can preserve the original window size?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the debug-mode panic with $env | explore, paging past the end and pressing the down arrow. Inspect crates/nu-explore/src/views/record/mod.rs around get_percentage and the WindowCursor/Cursor behavior described in the report. Done means reaching the end of the table and pressing down no longer triggers the debug assertion.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100