New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow unmanaged console output #179
Comments
This is a good one definitely a feature we’d like to support, however to do so we’ll need to add some additional functionality to both to the renderer as well as probably a special Anyway, this should be a fun one. We’ll keep this issue updated with progress. |
Thanks for your input @meowgorithm ! If there's anything I can help with, please do not hesitate to ask. I will try to help as much as I can |
I have a working approach to this. Right now I have it set up as a separate renderer for the sake of simplicity, and because the "AltScreen" mode is incompatible with the "log mode" @rfc2119 proposed, so putting them on the same object would require handling incompatible setup options. Changes to expose the renderer: #246 Happy to PR this in @meowgorithm. If you're ok with this approach, let me know if you'd prefer the to keep the Renderer internal and I can make this a feature flag on the standard renderer. |
Thanks for the info (and the PR!), @Adjective-Object. I'm inclined to keep the rendering interface internal for now as it (somewhat intentionally) hasn't been given the attention necessary for a public API. However, at a glance, your implementation seems to make sense. Would you be interested in submitting a PR against the standard renderer instead? I've been imagining the public interface as a // A command for printing above the output, with a final newline
func Println(...string) Msg
// A command for printing above the output, probably also with a newline (somewhat like log.Print)
func Printf(string, vars ...string) Msg I'd also probably leave word-wrapping as an exercise for the user, but open to your opinions here. Let me know what you think! |
I'm happy to open a PR against the standard renderer.
~~I'm of a split mind on whether to wrap or truncate printed lines. I struggle to think of a time I'd personally want to log "as if with println" without wrapping. But for the sake of consistency with the rest of the renderer I'm leaning towards truncating lines~~
EDIT: Realized after revisiting the code that truncation will happen anyway. Was thinking of an earlier iteration I wrote that had different logic in flush().
What do you think the behaviour of the Println() Cmd should be when in
AltScreen mode? I don't see a clean way to get an error to the user somehow
so the only option I can see is dropping the messages silently.
And thanks for the cool framework! This has been a joy to hack on :)
|
Is there a convenient place for consumers to get access to the widthe of the terminal for word wrapping themselves? Otherwise it might actually make sense as an option when calling Println / Printf, for ergonomics |
Yep, via a |
I’d simply not print anything and note in the doc comment that |
Just a note that this is now in |
Using bubbletea, I would like to have a progress bar similar to
apt
's:Progress bar is updated and the above text does not get cleared. I could not achieve this in bubbletea. The closest attempt I got resulted in an unexpected error (see this cast. the code is a modification of examples/spinners/main.go).
I have also tried using
bubbletea.ScrollDown()
but it instantly clears the screen. Any ideas ?The text was updated successfully, but these errors were encountered: