Change:
const lineHeight = this._configurationService.inspect(TerminalSettingId.LineHeight).value; if (typeof fontSize === 'number' && typeof defaultFontSize === 'number' && typeof lineHeight === 'number') { const scalar = (fontSize / defaultFontSize) <= 1 ? (fontSize / defaultFontSize) : 1; // must be inlined to override the inlined styles from xterm element.style.width = `${scalar * DecorationStyles.DefaultDimension}px`; element.style.height = `${scalar * DecorationStyles.DefaultDimension * lineHeight}px`; element.style.fontSize = `${scalar * DecorationStyles.DefaultDimension}px`; <del> // the first split terminal in the panel has more room if (element.closest(DecorationSelector.FirstSplitContainer)) { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeftFirstSplit}px`; } else { element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; } </del> <ins> element.style.marginLeft = `${scalar * DecorationStyles.MarginLeft}px`; </ins> } }

Discussion:
Ref From
When I turn off , the padding remains. When I turn off , the decorations go away for the current terminal, even though shell integration is still on for the terminal. The padding also remains in this case. Are either of these results expected?
I don't think we're considering the setting currently, could you create a new issue on that? For were you testing for terminals that were not the left-most split? The padding should always be 20px for the left-most terminal so the character grid aligns with the first panel title. !
We are considering that: It's working for me https://user-
This is by design But shell integration should not still be on for that terminal.
I just tested it with a non-leftmost terminal now. I can confirm the padding goes away when I disable the decorations. When I re-enable them, the padding reappears, but the decorations don't seem to show up for new commands.
that one's tracked in already

Testing :bug: success terminal command decorations are still rendered !
only reproes sometimes - regression related to the change that was reverted in . We should figure out why zsh sends the sequence for the viewport so that can be re-.
I bet I caused this in , need after a splice...
Upstream fix merged, updating now...
I'm having the same error on macOS.<img width="1346" alt="Screen Shot 2022-02-24 at 9 44 26 AM" src="https://user-"
Still seeing this: ! Version: 1.65.0-insider (user setup) Commit: Date: 2022-02-25T05:17:33.544Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0. Repro steps new pwsh terminal :bug: see success decorations
if you run , you should see them all cleared from the terminal. running in the terminal only clears the viewport.
are you scrolling? a gif might be helpful because I cannot reproduce
!
You might also be seeing
Oh--I thought running in the terminal was supposed to clear the decorations too. Seems a little weird that the command decorations would stick around--I would disable the decorations if that is the behavior moving forward since the dots become quite distracting: ! Terminal: Clear does clear out the decorations, btw.
I don't think we can do anything about not working as expected in pwsh/windows. can we?
conpty sends , should we be clearing markers whenever erase in display clears any line? Just not sure about when conpty reprints the screen, could delete all existing markers. If that doesn't work we could maybe check if the command was and handle it specially? Might be complicated though.
I think it would be easy to handle by checking if the command entered was clear or similar (could even do this per shell type since the command name may differ). More complicated and potentially destructive to clear the markers whenever erase in display is called imo. We can test it though.
Reopening to cover cases like this specially