Skip to content

WIP: Fall back to plain output when colors are unavailable - #3946

Open
slash-aech wants to merge 2 commits into
mimblewimble:stagingfrom
slash-aech:harsh
Open

slash-aech wants to merge 2 commits into
mimblewimble:stagingfrom
slash-aech:harsh

Conversation

@slash-aech

Copy link
Copy Markdown

Fixes #3925

Please note the changes in file src/bin/cmd/client.rs. Changed unwrap() to let _ = to ignore the error and fallback to plaintexts.
Uses this pr and reference for the changes.

Is not a breaking change

Does not contain new tests

Signed-off-by: slash-aech <harshitbenke@proton.me>
@slash-aech slash-aech changed the title WIP: ignored panics when color not supported WIP: Fall back to plain output when colors are unavailable Oct 1, 2026
@slash-aech
slash-aech marked this pull request as ready for review October 1, 2026 12:35
Comment thread src/bin/cmd/client.rs Outdated
writeln!(t, "{}", title).unwrap();
writeln!(t, "--------------------------").unwrap();
t.reset().unwrap();
let _ = t.reset();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this unwrap related to terminal at all as term::stdout().unwrap(); above, we need to handle these unwraps and do not ignore them.

@slash-aech slash-aech Oct 3, 2026 •

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, I went through src/bin/cmd/server.rs to use the reference as how the errors are handled and used following type for the same

if let Err(e) = t.reset() {
			error!("Failed to reset terminal: {}", e);
		}

Lemme know if that works or I'll change the approach to maybe explicit error handling using the Error enum at the bottom of the code as next step

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or if the errors should be displayed in the terminal that would be worked upon

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not what I asked, we should handle all such errors (unwraps) at such function, unrelated to this PR btw.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, if you'd like it to be handled it with return type Result<(), Error> maybe I can try to propagate the issues with the ? instead of just logging, although I'm not sure if that change would be a breaking change and might lead to bigger change than apparent.
Mind letting me know what steps I can work on now and types of changes can help the current case?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it means we can switch to println if terminal has problems

Comment thread src/bin/cmd/client.rs Outdated
.unwrap(),
};
e.reset().unwrap();
let _ = e.reset();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as comment above, this unwrap should not be ignored

@slash-aech

Copy link
Copy Markdown
Author

Thank you for the review, I'll get to them ASAP and let you know.

Signed-off-by: slash-aech <harshitbenke@proton.me>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants