Clear buffer clears the prompt

[aradalvand]

Windows Terminal version

1.22.10731.0

Windows build number

Other Software

No response

Steps to reproduce

This setting:

{
    "command": {
        "action": "clearBuffer",
        "clear": "all"
    },
    "id": "User.clearBuffer.87C324ED"
},

Now clears absolutely everything, ruins the prompt:

The screen recording below shows the VS Code terminal's clear buffer action first, which behaves exactly how Windows Terminal used to behave prior to the latest update (the prompt is preserved when buffer is cleared) — then you can see Windows Terminal's new clear buffer behavior, where it destroys the prompt, highly unexpected:

2025-03-27.07-47-28.mp4

Expected Behavior

Outlined and showed above.

Actual Behavior

Outlined and showed above.

It is an absolutely terrible UX choice to change the way such fundamental actions behave and disrupt people's muscle memory.

[dmillerkeyfive]

Same here. Subtle but feels like it's broken; seriously unbearable, lol

[aradalvand]

This is the PR that ruined everything: #17884

[xamir82]

Just noticed this. Please @lhecker go back and revert this behavior, or at least give us the option.

[lhecker]

As some of you may realize, I'm neither an emotionless robot nor a customer support agent. The way you phrase this request, including that other, deleted comment elsewhere, does not motivate me one bit to drop everything I'm working on and immediately address this.

If one of you would like to see this immediately fixed, the linked PR shows where you need to make the change. After all, that's why this project is on GitHub. Otherwise, I'll look into this when I get a chance.

P.S.: I consider Gnome Terminal a sane emulator.
P.P.S.: You're using a terminal feature for something that ought to be part of the shell, because it is then able to redraw the prompt. For instance: https://superuser.com/a/1806509

[j4james]

FYI, I've seen this problem discussed a few times in the VTE issue tracker, and I recall two proposals for figuring out how much of the screen you should retain when clearing the buffer.

1. If you consider the active cursor position as the end of the prompt line, you can attempt to work your way back to the start of the prompt by searching backwards for a hard line break. Because if you've got a wrapping line break, then the previous line is likely still part of the prompt, and thus should also be retained.
2. If the shell is setup to use the FTCS prompt marks, then the terminal is assumedly aware of the start and end of the current prompt, so it should know exactly how much of the screen is worth preserving. This could also help identify when you're in a full screen app that isn't using the alt buffer.

I may be misremembering the details, and I don't actually use this functionality myself, so it's possible I don't fully understand the problem, but hopefully the above information will be of some help to anyone wanting to work on this issue.

[MikeWang000000]

VScode's terminal and macOS's terminal are sane emulators too, I think. Clicking their "Clear" button, they both clear all scrollbacks but keep the text on the current line.

I often use this feature using a hotkey Ctrl + K to clear the history logs I don't need (just like the clear command, or the cls command in CMD). In this way, useless logs will not be matched by Ctrl + Shift + F, and also I don't want the shell prompt to disappear.

The commit changed the external behavior, so it made people who often use this feature a bit annoyed, and so am I at first. But after reading the comments, I think this modification is also reasonable.

Maybe we have different understandings of "Clear Buffer". In order to distinguish the two, I suggest adding a new "Clear History" option preserving the old behavior (clear scrollback + clear buffer but keep current line), and also keeping the current "Clear Buffer".