-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
fix linkifier after shrinking #1769
Conversation
if (endIndex[1] >= this._terminal.cols) { | ||
endIndex[1] = this._terminal.cols - 1; | ||
} | ||
const visibleLength = (endIndex[0] - bufferIndex[0]) * this._terminal.cols - bufferIndex[1] + endIndex[1]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does using visibleLength mean URLs will be broken if the viewport is shrunk?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
visibleLength is just there to give the marker the length to underline. This makes sure that the underline does not over- or underflow the real end of the URL. So after shrinking the underline should stick to chars that really belong to the URL. Side effect of this - after enlarging inserted empty cells are also underlined. To get rid of this, the underline marker would have to support multiple chunks to underline.
@Tyriar Can you test again? Now it gets very hacky, it also pulls in the problem of the empty cell representation. 😒 Not sure were this here will lead, kinda dont want to change the impl of |
// we cannot directly use uri.length here since stringIndexToBufferIndex would | ||
// skip empty cells and stop at the next cell with real content | ||
// instead we fetch the index of the last char in uri and advance to the next cell | ||
const endIndex = this._terminal.buffer.stringIndexToBufferIndex(rowIndex, stringIndex + uri.length - 1, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a problem case with always trimming:
What if we only trim the whitespace inside the shadowed content, so here the 2 spaces would still remain. This would open up a problem with echoing this and then sizing down twice:
But maybe that's a fine compromise until reflow as links without resizing will work then?
@Tyriar Im not sure anymore if this is fixable in a sane way without altering the trimming behavior (this will touch the empty cell representation and the NB: Also found another issue with 😒 😒 |
…jerch/xterm.js into fix_linkifier_after_shrinking
The last commit works regarding the linkifier as far as I have tested it, but contains those empty cells after enlarging, hmm. (Also a few tests dont pass since they test for the "faulty" behavior). |
…jerch/xterm.js into fix_linkifier_after_shrinking
Currently stalled by #1775. |
…jerch/xterm.js into fix_linkifier_after_shrinking
@Tyriar With #1775 the issue you described should be gone, also the original issue microsoft/vscode#61708 should be fixed now. The line now sticks correctly to the first and the last cell of the url char, even for surrogates and combining chars. Only weird behavior still is the "space extension" to the right after enlarging the terminal. Note that this is only a visual glitch, c&p of the url does not insert any spaces (returns correct url). Up for review. |
Partially blocked by #1864. Reminder: With reflow in place remove the hidden content workarounds as we dont need them anymore. |
Moved to #2115 |
Fix for microsoft/vscode#61708.
To get this working, I had to add a partial fix of the trim behavior ofReverted since it introduces to many side effects.Buffer.translateBufferLineToString
for lines that are longer than the currentTerminal.cols
and get new content (contains a generalized version of this commit 48bd634, thanks to @dnfield).