# 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?