1. when clicking rapidly i think it's interpreted as double or triple click and not handled - folding/unfolding doesn't work in that case
2. if cursor is currently placed inside the folded block (second line or more) the folding doesn't work - clicking does nothing, need to move the cursor manually out of the block
3. mouse wheel and moving down the file with cursor by pressing down key starting before the folded block - also produces weird results, see attached video
4. syntax highlighting seems sometimes broken by the folding - this could be a general syntax highlighting bug with incremental view, made worse by folding

All of the issues should have e2e tests that reproduce them before fixing so we ensure the fix is robust

Can you please squash to a handful of commits (separate if they are doing unrelated changes) with meaningful commit messages?

I just created a more detailed contribution guide - please read quickly (it's short), you can feed it into an LLM to apply on your branch: https://github.com/sinelaw/fresh/blob/master/CONTRIBUTING.md
Also please rebase on latest master because there are conflicts

There's still a bug with scrolling when code is folded:

It's looking better! Almost there.

1. Remaining bug I noticed: after folding a block, moving down causes a sudden jump and then moving back up - shows that the folding has been undone (not folded anymore). This doesn't happen when scrolling with mouse wheel
   Can you add an e2e test that fails on this (reproduces the bug) and then fix it?

2. Remove this file from the branch (amend the commit that added it) - 551772438-9be48c1a-15e0-4ac0-80c3-9adeff177969.mp4

3. Ctrl+click selection extension silently removed

The old handle_editor_click code had:
// Both modifiers supported since some terminals intercept shift+click
let extend_selection = modifiers.contains(KeyModifiers::SHIFT)
|| modifiers.contains(KeyModifiers::CONTROL);

4. Side-effectful fold removal in the render/layout path

compute_buffer_layout (split_rendering.rs:4886) mutates folds during rendering:
if !folds.is_empty() {
let cursor_positions: Vec = cursors.iter().map(|(_, c)| c.position).collect();
for pos in cursor_positions {
let _ = folds.remove_if_contains_byte(&mut state.marker_list, pos);
}
}

This means rendering is not idempotent -- re-rendering after cursor movement silently expands folds. This should be handled in the cursor movement / input handling layer, not during rendering. The render path should be read-only with respect to fold state. As-is, the fold auto-expand only triggers when a render happens, which creates a timing dependency.

5. Line numbers in large files are broken now. I'm guessing it's related to this change - from incremental line counting (prev_was_source_line + increment) to source-byte lookup (get_line_number(first_byte))
   // Before: if show_line_number && prev_was_source_line { current_source_line_num += 1; }
   // After: current_source_line_num = state.buffer.get_line_number(first_byte);

We should avoid using get_line_number - can we change it to be more incremental (lazy walking over lines until we fill up the view, skip rendering the lines that belong under the fold) and keep the +1 ? I'm not sure.

some changes are from clippy --fix

Please add this commit (cherry pick) to your branch, and see that the new test there passes: d90a9a6

Thanks! There's a few more bugs but I'll fix them in a new PR