Rethink compile failure UX: simple generic fallback, separate preset-specific summaries #70

New issue

Closed

opened 2026-04-15 00:56:47 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-15 00:56:47 +00:00

The current compile failure UX is trying to do too much in one place, and it is producing misleading summaries for LaTeX in particular.

Concrete examples from testing tonight:

empty or effectively useless failure messages are possible in the generic path
wrapped TeX output can produce truncated summaries like Emergenc
latexmk boilerplate can win instead of the real cause, e.g. Collected error summary (may duplicate other messages):
generic line scoring can even pick command echo text like Running 'pdflatex -file-line-error ...' because it contains the substring error

I think this needs to be split into two explicitly separate problems.

First, the generic layer should be minimal, simple, and reliable. It should not try to be clever. Out of the box, a compile failure should never render an empty string. The generic behavior should just canonicalize available process output into a short, non-empty preview snippet and make the full raw output accessible to users. In other words, keep the default summary boring and correct, and make the underlying compiler output easy to inspect.

Second, the preset-specific layer should be handled separately. That is where smarter summaries belong. For example, LaTeX almost certainly needs custom handling for wrapped messages and latexmk/pdflatex output shape. The same is likely true for other presets with their own output formats. This part is inherently more complex and should not be conflated with the generic fallback.

Suggested direction:

simplify the generic failure notifier so it always shows a non-empty, normalized snippet from the available output
explicitly expose the full compile output object/state so users can inspect it directly instead of forcing the notification to do all the work
add preset-level summary handling separately, where providers can override the generic fallback with something format-aware

Important scope note: both the generic layer and the preset-specific layer need work, but they should be fixed independently.

Also worth calling out explicitly: the preset-specific side will require manual testing across every built-in preset. This is not something we can safely treat as a purely abstract parser refactor. We should expect to literally test failing inputs and output rendering for each preset/configuration to make sure the summaries are actually better in practice.

A useful reference point here is VimTeX: it keeps the generic failure message simple, relies on structured parsing for LaTeX-specific detail, and exposes raw output / quickfix when parsing is insufficient. preview.nvim probably wants a similarly clean separation of responsibilities.

The current compile failure UX is trying to do too much in one place, and it is producing misleading summaries for LaTeX in particular. Concrete examples from testing tonight: - empty or effectively useless failure messages are possible in the generic path - wrapped TeX output can produce truncated summaries like `Emergenc` - latexmk boilerplate can win instead of the real cause, e.g. `Collected error summary (may duplicate other messages):` - generic line scoring can even pick command echo text like `Running 'pdflatex -file-line-error ...'` because it contains the substring `error` I think this needs to be split into two explicitly separate problems. First, the generic layer should be minimal, simple, and reliable. It should not try to be clever. Out of the box, a compile failure should never render an empty string. The generic behavior should just canonicalize available process output into a short, non-empty preview snippet and make the full raw output accessible to users. In other words, keep the default summary boring and correct, and make the underlying compiler output easy to inspect. Second, the preset-specific layer should be handled separately. That is where smarter summaries belong. For example, LaTeX almost certainly needs custom handling for wrapped messages and latexmk/pdflatex output shape. The same is likely true for other presets with their own output formats. This part is inherently more complex and should not be conflated with the generic fallback. Suggested direction: - simplify the generic failure notifier so it always shows a non-empty, normalized snippet from the available output - explicitly expose the full compile output object/state so users can inspect it directly instead of forcing the notification to do all the work - add preset-level summary handling separately, where providers can override the generic fallback with something format-aware Important scope note: both the generic layer and the preset-specific layer need work, but they should be fixed independently. Also worth calling out explicitly: the preset-specific side will require manual testing across every built-in preset. This is not something we can safely treat as a purely abstract parser refactor. We should expect to literally test failing inputs and output rendering for each preset/configuration to make sure the summaries are actually better in practice. A useful reference point here is VimTeX: it keeps the generic failure message simple, relies on structured parsing for LaTeX-specific detail, and exposes raw output / quickfix when parsing is insufficient. preview.nvim probably wants a similarly clean separation of responsibilities.