Skip to content
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

Smarter handling of wrapped lines on resize #14

Closed
wez opened this issue Feb 28, 2018 · 1 comment
Closed

Smarter handling of wrapped lines on resize #14

wez opened this issue Feb 28, 2018 · 1 comment
Labels
enhancement New feature or request

Comments

@wez
Copy link
Owner

wez commented Feb 28, 2018

If you have long lines and resize the window smaller, most other terminals will re-wrap the text to fit the new dimensions, and remember the original boundaries when the terminal is later sized larger.

@wez wez added the enhancement New feature or request label Feb 28, 2018
wez added a commit that referenced this issue May 26, 2019
This one has been bugging me for a while; we now know when we've
wrapped a line and can join it without a line break when double-clicking
to select a word.

This commit introduces a wrapped attribute to help record this
information, which could potentially help with when it comes
to looking at nicer resize behavior in refs: #14
wez added a commit that referenced this issue Jan 11, 2020
Adds logic to resize handling that will consider the original logical
line length when the width of the terminal is changed.

The intent is that this will cause the text to be re-flowed as if it had
been printed into the terminal at the new width.  Lines that were
wrapped due to hittin the margin will be un-wrapped and made into a
single logical line, and then split into chunks of the new width.

This can cause new lines to be generated in the scrollback when
making the terminal narrower.  To avoid losing the top of the buffer
in that case, the rewrapping logic will prune blank lines off the
bottom.

This is a pretty simplistic brute force algorithm: each of the lines
will be visited and split, and for large scrollback buffers this could
be relatively costly with a busy live resize.  We don't have much choice
in the current implementation.

refs: #14
@wez wez closed this as completed Jan 14, 2020
@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant