Support multiline tea.Println() messages

[Adjective-Object]

When logging something into the scrollback history of the standard renderer, the current approach temporarially increases the size of the UI by the number of logged messages. This has 2 issues:

• log lines are truncated according to the current width of the terminal UI. This truncation behaviour is desireable when writing into the TUI's controlled space, but is not desireable when Printf()ing messages into the scrollback, since the contents of the logged line will be truncated with no way to recover the history.
• User code pre-wrapping messages they want to print to the scrollback don't behave the way that you would want/expect log lines in a terminal to behave:
  • Resizing the terminal emulator does not reflow the lines to the new terminal's width
  • Manual wrapping breaks most terminal emulator's detection of clickable URLs and file paths

This change replaces that approach with a full clear of the previos UI + printing unwrapped messages into the terminal before the next render

this has a minor performance impact because it necessitates a full clear of the terminal UI on each Printf(). This breaks duplicate line detection between renders. However, the current approach will rarely hit duplicate line detection, since adding log messages to the front of the printout buffer offsets the new buffer. Therefore, the current line detection logic will only trigger when the buffer contains duplicate lines offset by the number of messages being logged in this render pass.

[meowgorithm]

Note: if merged, this closes #460

[Adjective-Object]

Oh, I'm sorry! I didn't see it already had an issue someone had intended to work on for hacktoberfest!

Didn't mean to step on anyone's toes, I've been kicking the can on this for a while and finally made this change this week because I have a deadline coming up.

[bashbunni]

@Adjective-Object no worries! Issues aren't reserved; it's first come, first serve

[knz]

Could we make this wrap the output instead of truncating it?

[Adjective-Object]

That's what the PR does.

…

On Fri, Oct 7, 2022, 08:55 knz ***@***.***> wrote: Could we make this wrap the output instead of truncating it? — Reply to this email directly, view it on GitHub <#490 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI62SXEISCGSYBELG4C65TWCAMSTANCNFSM6AAAAAAQ625UTA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adjective-Object]

Oh you mean with wordwrap? That has undesireable side effects I describe in the description: - println text does not reflow when resizing the terminal emulator - links and file paths that are manually wrapped partway through are not recognized by most terminal emulators

…

On Fri, Oct 7, 2022, 09:07 Maxwell Hobbs ***@***.***> wrote: That's what the PR does. On Fri, Oct 7, 2022, 08:55 knz ***@***.***> wrote: > Could we make this wrap the output instead of truncating it? > > — > Reply to this email directly, view it on GitHub > <#490 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAI62SXEISCGSYBELG4C65TWCAMSTANCNFSM6AAAAAAQ625UTA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[different55]

Looks like this PR is still fresh enough to apply, is there anything I could do to help this along? I've been running into the issue of unmanaged output not wrapping in one of my projects recently.

[Adjective-Object]

@meowgorithm, we've been using this fork internally at my work for a while, so it seems to be stable enough! Looks like I have a stray comment leftover from rebasing but other than that it should be good to look at in its current state

[meowgorithm]

@Adjective-Object Sounds good, let’s get this in. Thanks for your patience on this one!