You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains 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
@Tyriar I actually had to move the overscan ability to BufferStringIterator to deal with a possible worst case scenario where the buffer contains very very long unwrapped lines.
This might also be a problem at other places that try to unwrap line data.
The linkifier now has a class attribute LIMIT_OVERSCAN = 5 that allows to expand the unwrapping to a maximum of -5 for the top and +5 for the bottom viewport border. I think we want this value to be customizable or changeable at runtime, since it kinda limits any match at the borders to that size (an URI taking 6 lines will not match at the borders), which will lead to problems in small terminals. Not sure where to put this, maybe in the buffer class itself as an default overscan value, that changes with different buffer widths? Changed to class attribute LIMIT_CHAR_OVERSCAN = 2000, that does the overscan based on the actual terminal width.
I think we want this value to be customizable or changeable at runtime, since it kinda limits any match at the borders to that size (an URI taking 6 lines will not match at the borders), which will lead to problems in small terminals.
Why not just ballpark some number and accept the few failures that may occur? For example, scan 5 rows up or down, or maybe better scan x characters up or down (Math.ceil(charCount / cols) rows).
@Tyriar Ready for next review. I added range checks and a brute force test to be on the safe side. The iterator should not overflow the buffer for any argument now.
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.
Fixes #1691.
@Tyriar I actually had to move the overscan ability to
BufferStringIteratorto deal with a possible worst case scenario where the buffer contains very very long unwrapped lines.This might also be a problem at other places that try to unwrap line data.
The linkifier now has a class attributeChanged to class attributeLIMIT_OVERSCAN = 5that allows to expand the unwrapping to a maximum of -5 for the top and +5 for the bottom viewport border. I think we want this value to be customizable or changeable at runtime, since it kinda limits any match at the borders to that size (an URI taking 6 lines will not match at the borders), which will lead to problems in small terminals. Not sure where to put this, maybe in the buffer class itself as an default overscan value, that changes with different buffer widths?LIMIT_CHAR_OVERSCAN = 2000, that does the overscan based on the actual terminal width.