md-recent Path Elision Playground

This self-contained page exercises the proposed candidate-enumeration algorithm for the Markdown Recent Viewer. It keeps the filename whenever possible, scores complete path-segment candidates, and intentionally biases display budget toward folders near the filename.

What problem this page studies

The Markdown Recent Viewer shows files that were edited or written during the current Pi session. Each row has a fixed part, such as the selection marker, timestamp, and tool name, followed by a relative file path. The fixed part is predictable. The path is not. Some paths are short enough to show directly, while ticket documents and nested extension files can be much wider than the terminal row.

End truncation is the wrong default for this UI because it often removes the filename. The filename is the object the user is about to open, so the algorithm must preserve it whenever it fits. The folders closest to the filename are usually the next most useful information because they distinguish common names such as README.md, index.ts, and ui.ts. The beginning of the path still matters because it identifies the broad repository area, but it should not consume most of the available width.

1. Keep the target.The filename is shown in full whenever the filename itself fits inside the path budget.
2. Prefer nearby parents.Folders near the filename receive more score than folders near the path beginning.
3. Keep structure.The normal algorithm shows complete path segments and uses .../ only between preserved segments.

The algorithm in one pass

  1. If the full path fits, return it unchanged.
  2. Split the path into slash-separated segments. The final segment is the filename.
  3. If the filename alone does not fit, return a tail-preserving filename fallback such as …ending.markdown.
  4. Generate every middle-elided candidate made from a prefix slice, an ellipsis marker, and a suffix slice. Examples are foo/.../bla.md, foo/.../bar/bla.md, and .../three/four/bar/bla.md.
  5. Discard candidates whose visible width is greater than the path budget.
  6. Score each remaining candidate and choose the highest-scoring one.

The scoring rule

The playground uses a deliberately small scoring model. It does not try to understand project semantics. It only expresses display priorities over path structure. The suffix side has higher value because it contains the filename and the folders that disambiguate it. The prefix side has lower value, plus a one-time bonus for keeping some beginning context when it is affordable.

score = suffixCharsWeight × suffix character count + prefixCharsWeight × prefix character count + suffixSegmentsWeight × suffix segment count + prefixSegmentsWeight × prefix segment count + prefixPresenceBonus if at least one prefix segment is shown

The controls below expose these weights. Increasing suffix chars or suffix segs makes outputs move toward forms like foo/.../three/four/bar/bla.md. Increasing prefix chars, prefix segs, or prefix bonus makes outputs preserve more of the beginning, such as foo/one/.../bar/bla.md. The candidate table shows the exact alternatives and the score that made the selected candidate win.

Worked scoring examples

The default weights are suffix characters = 4, prefix characters = 1, suffix segments = 8, prefix segments = 2, and prefix presence bonus = 12. The table below uses the path foo/one/two/three/four/bar/bla.md. Slashes and the .../ marker affect width, but the score counts only the preserved path segment names.

Candidate Calculation Score What it means
.../four/bar/bla.md 4×15 + 1×0 + 8×3 + 2×0 + 0 84 No beginning context, but strong filename-side context.
foo/.../bar/bla.md 4×10 + 1×3 + 8×2 + 2×1 + 12 73 Keeps the top-level folder, but shows less suffix context.
foo/.../four/bar/bla.md 4×15 + 1×3 + 8×3 + 2×1 + 12 101 Keeps both the top-level folder and the richer filename-side context.
foo/one/.../bla.md 4×6 + 1×6 + 8×1 + 2×2 + 12 54 Spends characters on the beginning, so it loses too much suffix context.

The important comparison is not that every candidate must include foo. The important comparison is that foo/.../four/bar/bla.md beats foo/one/.../bla.md. That is the suffix bias in action: once the filename is safe, nearby parent folders usually explain more than extra leading folders.

Inputs

78
0

Scoring Weights

score = suffixChars × suffix character count + prefixChars × prefix character count + suffixSegs × suffix segment count + prefixSegs × prefix segment count + prefixBonus when prefix is shown

Higher suffix weights mean more characters and complete folders near the filename win over additional beginning folders.

Benchmark

No benchmark yet.

Focused Result

List Preview

Candidate Table

chosen candidate width score prefix suffix