Amazing! I was actually thinking about this recently, so this PR comes at a great time :)

I'll review it soon, thanks in advance though 😀

@Norbert515 Oh good, glad to hear it's welcome! If you spot anything you want me to change, just let me know (or feel free to take matters into your own hand, too). 🤠

Follow-up: Improvement Suggestions Based on Research

I did some deeper research into potential improvements for this PR. Here are concrete suggestions organized by priority:

🚀 Performance Improvements

1. Cache Selectables & Invalidate on Layout (HIGH IMPACT, LOW RISK)

Currently _collectSelectables() walks the entire render subtree on every mouse move during drag. This is the biggest bottleneck.

Suggested fix:

class RenderSelectionArea extends RenderMouseRegion {
  bool _selectablesCacheValid = false;
  
  @override
  void markNeedsLayout() {
    super.markNeedsLayout();
    _selectablesCacheValid = false;  // Invalidate on layout
  }
  
  List<Selectable> _collectSelectables(RenderObject root) {
    if (_selectablesCacheValid && _cachedSelectables.isNotEmpty) {
      return _cachedSelectables;  // Return cached
    }
    
    // Do the expensive tree walk & sort only when needed
    _cachedSelectables = /* ... existing logic ... */;
    _contextLists = _buildContextLists(_cachedSelectables);
    _selectablesCacheValid = true;
    return _cachedSelectables;
  }
}

Impact: Reduces tree walks from ~60/second (during drag) to ~1 per layout change.

2. Incremental Selection Updates (HIGH IMPACT, MEDIUM RISK)

Currently _updateSelectionRanges() iterates ALL selectables on every move. Instead, track the previous selection range and only update selectables whose state changed:

void _updateSelectionRanges(...) {
  int newStartIdx = math.min(anchorIdx, focusIdx);
  int newEndIdx = math.max(anchorIdx, focusIdx);
  
  // Only iterate the union of old and new ranges
  for (int i = math.min(_lastStartIdx ?? newStartIdx, newStartIdx); 
       i <= math.max(_lastEndIdx ?? newEndIdx, newEndIdx); i++) {
    final wasSelected = i >= (_lastStartIdx ?? newStartIdx) && i <= (_lastEndIdx ?? newEndIdx);
    final isSelected = i >= newStartIdx && i <= newEndIdx;
    
    if (wasSelected != isSelected) {
      // Only update if state changed
      if (isSelected) {
        entries[i].selectable.setSelectionRange(...);
      } else {
        entries[i].selectable.clearSelection();
      }
    }
  }
  
  _lastStartIdx = newStartIdx;
  _lastEndIdx = newEndIdx;
}

Impact: For 1000 selectables with selection of 10 items, updates ~10 items instead of ~1000.

3. ListView: Use Parent Data for Position Estimation (HIGH IMPACT for variable-extent)

Currently _forceBuildSelectionRange() with variable extents walks from index 0 to calculate positions. Instead, use _averageItemExtent (already tracked at line 691) or existing parent data:

void _forceBuildSelectionRange({...}) {
  // Skip the 0..minIndex walk for variable extent lists
  double currentPosition = _estimatePositionForIndex(minIndex);
  
  for (int index = minIndex; index <= maxIndex; index++) {
    final renderObject = _buildAndLayoutChild(
      index: index,
      layoutOffset: currentPosition,
    );
    // ...
  }
}

double _estimatePositionForIndex(int index) {
  // Check existing parent data first
  for (final child in _allChildren) {
    final pd = child.renderObject.parentData as ListViewParentData?;
    if (pd?.index == index && pd?.layoutOffset != null) {
      return pd!.layoutOffset!;
    }
  }
  // Fall back to average extent estimate
  return index * (_averageItemExtent ?? 1.0);
}

Impact: Selecting items 500-550 builds ~50 items instead of ~550.

🏗️ Architecture Improvement: Replace Global State with InheritedComponent

The SelectionDragState global class works but has limitations (multiple SelectionAreas interfere, test isolation issues). Nocterm already has InheritedComponent support (see TuiTheme).

Suggested approach:

// New file: lib/src/components/selection_scope.dart
class SelectionScope extends InheritedComponent {
  final SelectionController controller;
  
  const SelectionScope({
    super.key,
    required this.controller,
    required super.child,
  });
  
  static SelectionController? maybeOf(BuildContext context) {
    return context
        .dependOnInheritedComponentOfExactType<SelectionScope>()
        ?.controller;
  }
  
  @override
  bool updateShouldNotify(SelectionScope old) => controller != old.controller;
}

class SelectionController {
  bool _isActive = false;
  final Map<Object, SelectionRange> _ranges = {};
  
  bool get isActive => _isActive;
  void begin() => _isActive = true;
  void end() { _isActive = false; _ranges.clear(); }
  void updateRange(Object context, int minIndex, int maxIndex) { ... }
  SelectionRange? rangeFor(Object context) => _ranges[context];
}

Migration path:

1. Add SelectionScope/SelectionController alongside existing global state
2. Update SelectionArea to use controller and wrap child with SelectionScope
3. Update RenderListViewport to check SelectionScope.maybeOf(context) with fallback
4. Remove global state once stable

Benefits:

• Multiple SelectionArea widgets work independently
• Tests are isolated (each creates own controller)
• Follows nocterm's existing patterns (TuiTheme)
• Easy to extend with additional configuration

📊 Summary

I'd recommend implementing the caching first (biggest win, lowest risk), then the incremental updates. The InheritedComponent refactor can be a follow-up PR.

These are just suggestions - the current implementation is already solid and functional! Happy to help implement any of these if you're interested.

Additional Thought: ListView Lazy Mode

One more architectural consideration - the current approach of temporarily disabling lazy mode during selection drag (_forceBuildSelectionRange) is a bit heavy-handed.

Instead of force-building all items in the selection range, we could leverage the existing parent data infrastructure more directly:

1. Keep ListView lazy - Don't force-build items outside the viewport
2. Use parent data for selection tracking - The ListViewParentData already stores layoutOffset, extent, and index for built items
3. Build on-demand for text extraction - Only when _collectSelectedText() is called (on mouse up), build the items needed for text extraction

This would mean:

• Selection highlighting only shows for items currently in the viewport (which is what the user sees anyway)
• Text extraction happens once at the end, not continuously during drag
• ListView stays performant even with huge lists

The current implementation works correctly, but forcing non-laziness for potentially thousands of items during a drag operation could cause jank. Using parent data to track what would be selected, without actually building those items, would be more aligned with the lazy philosophy.

What do you think @jolexxa? This could be a follow-up optimization if the current approach causes performance issues in practice.

Hey! I've let me Claude do an extensive check of the PR, sounds very reasonable what it found. How shall we proceed, would you like to continue working on this or shall I take it over? I'm fine either way! :)

Hey! I think your claude is picking up on a lot of good points. By all means, please take over (I don't think I'm giving enough money to Anthropic each month to steer an Opus on these changes in any reasonable amount of time). I'm still playing with this locally and trying to see how robust it is. Certain layouts don't always seem to "just work" but I've yet to figure out why. Additionally, this doesn't have support for MarkdownText.

I would probably encourage you to do the "don't build all items in selection" as a follow-up PR. It's not been a huge problem and there are extraordinary correctness challenges involved. I tried several different approaches, and the only one which ended up working well in the end was the dumb "build everything" one. I'm sure it can be done, but it's probably not trivial.

Oh, and the app I'm using nocterm for is now public.

i'm very happy to see all the activity on this 🤠

I think it's mostly good to go for now! Any subsequent changes should just be implementation details, I'll merge this in a minute!

Also, cow looks really nice! I was thinking of setting up a 'Made with Nocterm' some time, do you mind if I showcase it there?

@Norbert515 ooh, nice to see it merged! i'll try it out in Cow as soon as I get a chance. And thank you! feel free to showcase it! it's a silly project but it's been fun to poke at