feat(presets): add failure summaries preset by preset #81

Closed
opened 2026-04-25 21:38:53 +00:00 by barrettruth · 0 comments
barrettruth commented 2026-04-25 21:38:53 +00:00

Follow-up to #70.

Problem

The general failure path should stay boring and correct. The remaining quality gap is in provider-aware summaries, and the only way to call #81 done is to audit every built-in preset with explicit positive and negative coverage.

Trying to solve this with a stronger global heuristic would repeat the same problems that motivated #70 in the first place. The better path is incremental, preset-by-preset work, with real tool output and both automated and manual validation.

Status

The provider-level failure_summary(result, ctx) API landed in #86. This issue now tracks the preset-specific work that uses that API.

Tracking

Quality bar for every child issue

  • Positive path: representative valid document compiles successfully and does not surface a failure summary.
  • Primary negative path: canonical failure produces the intended one-line summary, with the exact string asserted in tests.
  • Noisy negative path: boilerplate, wrapped output, repeated errors, or CLI noise still produce the correct summary.
  • Fallback path: if no trustworthy summary exists, behavior falls back cleanly to the generic failure or :Preview output hint path.
  • Raw output remains available through :Preview output and preview.result().
  • Automated coverage lands in repo specs/fixtures.
  • Manual validation runs in nix develop .#presets against the real toolchain.

Direction

  • Start with the presets where the gap is most obvious (LaTeX first).
  • Prefer provider-aware parsing and prioritization over generic line scoring from raw output.
  • Keep :Preview output as the raw fallback and keep the generic notification minimal.
Follow-up to #70. ## Problem The general failure path should stay boring and correct. The remaining quality gap is in provider-aware summaries, and the only way to call #81 done is to audit every built-in preset with explicit positive and negative coverage. Trying to solve this with a stronger global heuristic would repeat the same problems that motivated #70 in the first place. The better path is incremental, preset-by-preset work, with real tool output and both automated and manual validation. ## Status The provider-level `failure_summary(result, ctx)` API landed in #86. This issue now tracks the preset-specific work that uses that API. ## Tracking - [x] #88 `latexmk` - [x] #89 `pdflatex` - [x] #90 `tectonic` - [x] #91 `typst` - [x] #92 `markdown` - [x] #93 `github` - [x] #94 `quarto` - [x] #95 `asciidoctor` - [x] #96 `plantuml` - [x] #97 `mermaid` ## Quality bar for every child issue - Positive path: representative valid document compiles successfully and does not surface a failure summary. - Primary negative path: canonical failure produces the intended one-line summary, with the exact string asserted in tests. - Noisy negative path: boilerplate, wrapped output, repeated errors, or CLI noise still produce the correct summary. - Fallback path: if no trustworthy summary exists, behavior falls back cleanly to the generic failure or `:Preview output` hint path. - Raw output remains available through `:Preview output` and `preview.result()`. - Automated coverage lands in repo specs/fixtures. - Manual validation runs in `nix develop .#presets` against the real toolchain. ## Direction - Start with the presets where the gap is most obvious (LaTeX first). - Prefer provider-aware parsing and prioritization over generic line scoring from raw output. - Keep `:Preview output` as the raw fallback and keep the generic notification minimal.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
barrettruth/preview.nvim#81
No description provided.