starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Clear buffer clears the prompt #23081

New Issue
Closed
opened 2026-01-31 08:31:45 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 08:31:45 +00:00
Owner
Copy Link

Originally created by @aradalvand on GitHub (Mar 27, 2025).

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:

https://github.com/user-attachments/assets/eb0c3d36-a532-442a-968b-49cd2b601ca3

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.

Originally created by @aradalvand on GitHub (Mar 27, 2025). ### 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: https://github.com/user-attachments/assets/eb0c3d36-a532-442a-968b-49cd2b601ca3 ### 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.
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@dmillerkeyfive commented on GitHub (Mar 27, 2025):

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

@dmillerkeyfive commented on GitHub (Mar 27, 2025): Same here. Subtle but feels like it's broken; seriously unbearable, lol
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@aradalvand commented on GitHub (Mar 27, 2025):

This is the PR that ruined everything: https://github.com/microsoft/terminal/pull/17884

@aradalvand commented on GitHub (Mar 27, 2025): This is the PR that ruined everything: https://github.com/microsoft/terminal/pull/17884
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@xamir82 commented on GitHub (Mar 27, 2025):

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

@xamir82 commented on GitHub (Mar 27, 2025): Just noticed this. Please @lhecker go back and revert this behavior, or at least give us the option.
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Mar 27, 2025):

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

@lhecker commented on GitHub (Mar 27, 2025): 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
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Mar 27, 2025):

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.

@j4james commented on GitHub (Mar 27, 2025): 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.
claunia commented 2026-01-31 08:31:47 +00:00
Author
Owner
Copy Link

@MikeWang000000 commented on GitHub (Mar 28, 2025):

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".

@MikeWang000000 commented on GitHub (Mar 28, 2025): 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".
claunia commented 2026-01-31 08:31:48 +00:00
Author
Owner
Copy Link

@elibarzilay commented on GitHub (Apr 6, 2025):

@lhecker

  • There's no need to get insulted: you made a value call which dismissed the behavior of many people (and even labeled it with a subjective "I felt ... not much merit"), it is only expected that some of these people will be vocal about things that broke.

  • You're also the author of the code. Just submitting a PR that reverts the change is easy enough, but it would be justified to ask for tests or whatever to avoid going back and forth with changing it. Again, you're the most obvious person for doing that.

    • As a sidenote, I'll be happy to submit such a PR, though from my POV this would be rude since it's not my code.

  • Your comment + pointer about a terminal feature vs a shell feature is wrong: it cannot be a shell feature, since it needs to work also when the shell has no control (when something is running since there is no active prompt). This means that it must be implemented by the terminal itself.

  • And when a non-shell-interactive situation is considered, the previous behavior gets one more point to its credit: what if I have some code that prints out lines slowly, and I run the clear command mid-line? In this case it might be desirable (and probably a popular choice) to again clear the buffer except for the current line. Obviously, it would break things if the current line is married to the previous one (eg, one line shows error in line 123: and the next line the actual error message) -- but the whole thing is about human interactions anyway, so it's a rough functionality no matter what.

    Similarly, you're probably right that things were broken if the prompt has multiple lines -- but again, this is human interaction, and such prompts are much more rare than single lines. More than that: with the current behavior of clearing everything, if I want to clear the buffer and continue with my prompt, I'd clear it and then press ctrl+l (assuming that it redraws the current prompt line). With the previous behavior, the ctrl+l is not needed -- at the cost of breaking a multi-line prompt, but the same ctrl+l can fix that breakage. So overall, I need to use that second keypress much more rarely (multilines) than I do now (always).

@elibarzilay commented on GitHub (Apr 6, 2025): @lhecker * There's no need to get insulted: you made a value call which dismissed the behavior of many people (and even labeled it with a subjective "I felt ... not much merit"), it is only expected that some of these people will be vocal about things that broke. * You're also the author of the code. Just submitting a PR that reverts the change is easy enough, but it would be justified to ask for tests or whatever to avoid going back and forth with changing it. Again, you're the most obvious person for doing that. * As a sidenote, I'll be happy to submit such a PR, though from my POV this would be rude since it's not my code. * Your comment + pointer about a terminal feature vs a shell feature is wrong: it *cannot* be a shell feature, since it needs to work also when the shell has no control (when something is running since there is no active prompt). This means that it must be implemented by the terminal itself. * And when a non-shell-interactive situation is considered, the previous behavior gets one more point to its credit: what if I have some code that prints out lines *slowly*, and I run the clear command mid-line? In this case it might be desirable (and probably a popular choice) to again clear the buffer except for the current line. Obviously, it would break things if the current line is married to the previous one (eg, one line shows `error in line 123:` and the next line the actual error message) -- but the whole thing is about human interactions anyway, so it's a rough functionality no matter what. Similarly, you're probably right that things were broken if the prompt has multiple lines -- but again, this is human interaction, and such prompts are much more rare than single lines. More than that: with the current behavior of clearing everything, if I want to clear the buffer and continue with my prompt, I'd clear it and then press `ctrl+l` (assuming that it redraws the current prompt line). With the previous behavior, the `ctrl+l` is not needed -- at the cost of breaking a multi-line prompt, but the same `ctrl+l` can fix *that* breakage. So overall, I need to use that second keypress much more rarely (multilines) than I do now (always).
claunia commented 2026-01-31 08:31:48 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Apr 6, 2025):

I wrote "Fix" in "Fix clear buffer command", because the behavior you get when you revert my PR is that the command doesn't work at all. As such you base your comment on a false premise of me not wanting to revert the PR even though I would've already done that if it was possible.

I'll be collapsing both your and my comment as it is not necessary to convince me of making the change either.

@lhecker commented on GitHub (Apr 6, 2025): I wrote "Fix" in "Fix clear buffer command", because the behavior you get when you revert my PR is that the command doesn't work at all. As such you base your comment on a false premise of me not wanting to revert the PR even though I would've already done that if it was possible. ~~I'll be collapsing both your and my comment as it is not necessary to convince me of making the change either.~~
claunia commented 2026-01-31 08:31:48 +00:00
Author
Owner
Copy Link

@elibarzilay commented on GitHub (Apr 6, 2025):

Um ... I don't know what was fixed ("no implicit output"?), but the bottom line is that from my POV I don't see what was fixed, but I do see what was broken. This issue was opened by other people who have a similar view.

And I don't get the quasi-censorship: your earlier comment says "when I get a chance", the backlog label reads like "whenever", and meanwhile specific stuff is broken.

@elibarzilay commented on GitHub (Apr 6, 2025): Um ... I don't know what was fixed ("no implicit output"?), but the bottom line is that from my POV I don't see what was fixed, but I do see what was broken. This issue was opened by other people who have a similar view. And I don't get the quasi-censorship: your earlier comment says "when I get a chance", the `backlog` label reads like "whenever", and meanwhile specific stuff is broken.
claunia commented 2026-01-31 08:31:48 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Apr 6, 2025):

I don't know what was fixed

@elibarzilay When you view the description for PR #17884, you'll note the text: "Closes #17867". That blue number is a clickable link, and will take you to the issue that was fixed by the PR. I'd encourage you to actually read the issue, but the bottom line is that the Clear buffer command was broken - it literally had no effect.1 If you think you can do a better job of fixing that issue, I'm sure a PR contribution would be welcome, but "just submitting a PR that reverts the change" will simply leave you with a Clear buffer command that does nothing. I'm fairly certain that's not what anyone wants.

  1. ETA: It's possible it may still have cleared the scrollback if you had one - but no effect on the visible buffer. ↩︎

@j4james commented on GitHub (Apr 6, 2025): > I don't know what was fixed @elibarzilay When you view the description for PR #17884, you'll note the text: "Closes #17867". That blue number is a clickable link, and will take you to the issue that was fixed by the PR. I'd encourage you to actually read the issue, but the bottom line is that the `Clear buffer` command was broken - it literally had no effect.[^1] If you think you can do a better job of fixing that issue, I'm sure a PR contribution would be welcome, but "just submitting a PR that reverts the change" will simply leave you with a `Clear buffer` command that does nothing. I'm fairly certain that's not what anyone wants. [^1]: ETA: It's possible it may still have cleared the scrollback if you had one - but no effect on the visible buffer.
claunia commented 2026-01-31 08:31:48 +00:00
Author
Owner
Copy Link

@aradalvand commented on GitHub (Apr 6, 2025):

Your comment + pointer about a terminal feature vs a shell feature is wrong: it cannot be a shell feature, since it needs to work also when the shell has no control (when something is running since there is no active prompt).

Yeah, exactly.

@aradalvand commented on GitHub (Apr 6, 2025): > Your comment + pointer about a terminal feature vs a shell feature is wrong: it cannot be a shell feature, since it needs to work also when the shell has no control (when something is running since there is no active prompt). Yeah, exactly.
claunia commented 2026-01-31 08:31:49 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Apr 6, 2025):

Thanks all for participating! This discussion has gotten a bit too heated and we have clear next steps, so I'm going to lock it to avoid its descent into chaos.

@DHowett commented on GitHub (Apr 6, 2025): Thanks all for participating! This discussion has gotten a bit too heated and we have clear next steps, so I'm going to lock it to avoid its descent into chaos.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Help Wanted Issue-Bug Needs-Tag-Fix Priority-3 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#23081
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?