FastSense: add overlay remove*/clear* family (removeLine/clearLines, removeThreshold/clearThresholds, …) — the missing removal side of add*

[HanSur94]

Problem / motivation

FastSense has a full pre-render overlay add* family — addLine (FastSense.m:380), addThreshold (m:595), addBand (m:685), addMarker (m:742), addShaded (m:831), addFill (m:918) — but no remove* / clear* counterpart. Every add* method errors if IsRendered (FastSense:alreadyRendered, m:417), so overlays are strictly pre-render config, held in plain struct arrays (Lines/Thresholds/Bands/Markers/Shadings, m:98–112).

Because the config is append-only, a programmatic builder that assembles a FastSense from a template or a config flag has exactly one escape hatch when it needs to drop a previously-added line or threshold: throw the whole object away and rebuild it. There is no way to make the pre-render config editable.

Verified unfiled: searched removeLine, clearLines, removeMarker, remove threshold, remove band, clear thresholds — no existing open/closed issue covers this.

Proposed feature

A symmetric pre-render removal side for the overlay families:

• removeLine(idx) / clearLines()
• removeThreshold(idx) / clearThresholds()
• (follow-the-pattern siblings) removeBand/clearBands, removeMarker/clearMarkers, removeShaded/clearShadings, removeFill/clearFills
• optional umbrella clearOverlays() that empties all kinds

Minimal viable slice: removeLine/clearLines + removeThreshold/clearThresholds (the two most-used kinds); the rest can land as a mechanical extension.

Rough sketch

• Lib/class: libs/FastSense/FastSense.m — a small methods (Access = public) block next to the add* family.
• Public API shape:

  fp.removeLine(idx);      % remove the idx-th added line
  fp.clearLines();         % remove all added lines
  fp.removeThreshold(idx);
  fp.clearThresholds();

• Implementation: the overlays are struct arrays, so removal is just struct-array editing:

  obj.Lines(idx) = [];   % removeLine
  obj.Lines(:)   = [];   % clearLines

  Mirror the existing FastSense:alreadyRendered guard so removal keeps the same before-render contract as add*. Validate idx against numel(obj.Lines) (FastSense:badIndex).
• Product micro-decision to flag: remove by index (as sketched, matching add-order) vs. by label/DisplayName. Recommend index for the first cut; a label overload can follow.

Value

Makes the pre-render overlay config editable instead of append-only. Concrete scenarios: a helper adds a standard set of reference thresholds and a caller suppresses one for a particular sensor; or a partially-built plot is reused with its data lines cleared and re-added — without discarding and reconstructing the whole FastSense.

Constraints check

• Toolbox-free: ✅ pure struct-array indexing.
• Backward-compatible: ✅ strictly additive new methods; no signature or behavior change to add*/render. FastSense config is not serialized, so there is no dashboard/JSON round-trip impact.
• Pure MATLAB/Octave: ✅ no MEX, no toolbox.
• Widget/Tag contracts: untouched.
• Render lifecycle: untouched — removal is pre-render only (guarded by IsRendered), so there is no graphics-handle teardown and no relayout — this is what keeps the change clean.

Effort estimate

S. ~2 tiny methods per overlay kind + one focused test (assert count-after-remove, index validation, and the post-render alreadyRendered guard).

---

AI-proposed via /feature-scout — needs a human product decision before implementation.