fix(tui): friendly, consistently-coloured status-bar error messages - #99
Merged
Conversation
The interactive viewer's status bar surfaced three failure paths as raw Go error strings: opening a file that could not be read, saving an extracted file, and (silently, in the size fetch) an inspect failure during loading. - File-open and save-extract failures now route through the same friendly renderer the load path uses, so a mid-session daemon dropout or a removed file reads as a sentence instead of an internal error. - Save write failures gate the disk-space hint on ENOSPC and name only the chosen file, so the internal temp-file path no longer leaks to the user. - An image-size fetch that fails on its own during loading now shows a brief status warning instead of leaving the loading screen blank with no reason.
The status bar chose its colour by testing whether the message began with the literal prefix 'Error:'. The friendlier viewer, save, and inspect messages introduced alongside this no longer start with that word, so they would have rendered in the success (green) colour. Drive the colour from intent instead of the message text: a statusIsError flag set by a dedicated setErrorStatus helper and cleared by setStatus and on status expiry. All failure paths — the four async result messages and the five interactive guards — now route through it, so error voice and colour are consistent. Also strip the internal spool path from save write errors that are not disk-full, matching the disk-space path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Polishes the interactive TUI's error handling so failures show readable, actionable messages in the status bar — and always in the error colour.
Three status-bar failure paths previously surfaced raw internal error strings, and one failure was dropped silently:
Consistent error colour
The status bar previously picked its colour by checking whether the message began with the literal word "Error:". Because the friendlier messages above no longer start with that word, they would have rendered in the success (green) colour. The colour is now driven by intent — a flag set on failure and cleared on success — so every failure shown in the status bar renders in the error colour, and the five interactive guard messages ("cannot extract a directory", "file was removed in this layer", "extractor unavailable") are covered too.
Testing
go build ./...andgo vet ./...clean.