# Notes:
- Want to enable "scroll off", which means selection will
never get with N lines of the top or bottom of the screen.
- When jumping to an element that's above the top scroll-off,
that element should then be focused at line N.
- When hitting down arrow repeatedly, or jumping past the bottom,
the element should appear at line H - N.
- vim sometimes puts the newly focused element in the middle, but
it's not exactly clear when it does this; perhaps if it's a "big
enough" jump? (How big is enough?)
- When scrolling with C-e/C-y, focus automatically moves as well
when it gets pushed out of scroll-off zone
- If implementing something like "collapse me and all my siblings",
then the lines above the currently focused element could change.
## Line Wrapping:
- Wow, line wrapping makes this all super hard
- Can detect string widths using `unicode_width`
- How accurate is it?
- For emojis and other things, probably _over_estimates width, which
is good.
- If there's a bug with some crazy characters that's fine
- If just goes one extra line, then just means that scroll off might
be off in places (it'll just push top of the screen off)
- Maybe impossible to see the top of the screen (if implementation
is buggy)
- What about SUPER long strings that fill entire screen.
- I don't care
- Really only makes optimizations that redraw only parts of the screen more difficult
- INITIALLY, won't support wrapping, and will automatically condense
long strings / inlined objects
- Will assume that we won't have super indented objects, or super long
object keys.
## How to implement all of this?
### First step:
- Support rendering from a certain point, but fill the screen.
- This needs to support starting at a closing brace
- This sort of reference to a starting point is different than a
focus, but maybe just (focus, start_or_end (_or_primitive ?))
- Similar issue with container state (expanded/inlined/collapsed),
where we only want that state to apply to containers; here we only
want start/end to apply to containers, and not primitives.
- Probably just use a simple bool / 2/3-state enum.
- Maybe primitives also use start? an inlined / collapsed container
is basically a primitive.
### Next step:
- When changing focus, figure out what line the focused element will
be on, by starting at "start" point and walking the tree forward until
we find focused element.
- Walking this structure is 'easy' (linear), only need to walk # of lines
in screen, before giving up.
- If focused element isn't on screen, we can work backwards from where we
want it to be to get "start" location of screen
### Algorithm:
## Optimizations:
- It'd be great if we didn't have to print the whole screen each time.
- Actually would it be "great", is printing whole screen each time slow?