[vim/vim] Command-line mode transition bypassed by high-speed terminal paste stream (Issue #20817)
drjoms
drjoms created an issue (vim/vim#20817)Steps to reproduce
Description:
When pasting a string of text that begins with a colon (:) in a terminal session, the editor fails to enter COMMAND-LINE mode. Instead of the : character triggering the transition from NORMAL mode, the entire string—including the leading colon—is treated as a raw text stream and inserted directly into the buffer, as if the editor were already in an input/insert mode.
This behavior has been verified to be consistent across multiple terminal emulators, desktop environments, and connection protocols, indicating the issue resides within the Vim process/input-handling logic rather than the terminal or network layer.
Environment:
Vim Version: 9.1
Tested Environments:
Local (GNOME): GNOME Terminal on GNOME 49 (Gentoo)
Local (KDE): Konsole on GNOME 49 (Gentoo)
Remote: SSH on RHEL 10
Steps to Reproduce:
Open Vim in NORMAL mode.
Copy a command string starting with a colon (e.g., :set expandtab tabstop=2 shiftwidth=2).
Perform a "Paste" operation of the string into the Vim window (via Right-click or keyboard shortcut).
Technical Analysis:
There appears to be a priority conflict in the input-handling logic during high-speed data bursts. When a paste event occurs, the terminal delivers the character burst at a rate that outpaces the Vim process's ability to complete the state transition from NORMAL to COMMAND-LINE mode. The application appears to prioritize the incoming data stream as an "Insert" event, effectively hijacking the mode transition and treating the command trigger (:) as part of the text payload.
Expected behaviour
Expected Behavior:
The : character should be recognized as a command trigger, transitioning the editor from NORMAL mode to COMMAND-LINE mode. The remaining characters in the paste should then be buffered into the command-line entry for execution.
Actual Behavior:
The editor does not enter COMMAND-LINE mode. The entire string is inserted into the file as text, effectively treating the : as part of the data stream rather than a mode-change instruction. It seems like it was added there in "INPUT" mode.
Version of Vim
Vim Version: 9.1
Environment
Gentoo/RHEL 10.2
Gnome terminal: echo $TERM
xterm-256color
Version 3.58.0 for GNOME 49
Konsole
Version 26.04.3
echo $TERM
xterm-256color
Logs and stack traces
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20817)I believe this is Vim preventing nasty side effects happening during brackted paste mode. If you do not like it, try to disable it: :h xterm-brackted-paste
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)I am NOT using any modes.
vanilla "vi text.txt", enter
Mouse right click -> paste -> :set expandtab tabstop=2 shiftwidth=2
Vanilla VIM with no customizations. (on RHEL for sure, as its new VM)
I believe this is Vim preventing nasty side effects happening during brackted paste mode. If you do not like it, try to disable it:
:h xterm-brackted-paste
I don't know what that behavior is - it introduced, what I believe it to be, a bug.
I can work around for now, thanks for suggestion. But I believe this is a problem and needs to be resolved.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)It's a feature, not a bug.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)I see the value in your point regarding the security of the bracketed paste protocol; I understand why the safety mechanism exists. However, I think we are looking at this from two different perspectives: security vs. usability.
From a user's perspective, if a behavior isn't covered in vimtutor or the standard man pages, it feels like a bug because it breaks the fundamental expectation of how the editor responds to input. Even if a bug is documented, if it breaks the user's mental model, it still impacts the quality of the experience.
Rather than arguing over whether this is a "bug" or a "feature," I’d like to propose that we meet halfway.
I am not suggesting we remove the security mechanism. Instead, I am suggesting VIM team adds transparency. If Vim intercepts a paste that contains command-trigger characters, it should provide a brief visual indicator or status message explaining why the command was treated as literal text. This preserves the security you are aiming for while solving the "silent failure" that frustrates the user.
Ideally such message should stay on the screen for couple of seconds. Ideally right next to where code will be pasted in text documented.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20817)The Vim documentation is much more extensive then what can be covered in manpages or the vimtutor. As such, you should get familiar with the existing help system and read that.
On the visual change suggested, I am not sure. It seems a bit complex and seems not to add much benefit (Note, bracketed paste mode has been introduced years ago and no-one complained about this before)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)Also I would like to point out a question - for some reports, made by some users, how many users encounter, what they perceive to be issues and don't report it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)There is not a failure or a security feature. It's just a normal feature.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)I won't argue semantics, can we please implement this IMHO, useful, suggestion?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)It's not entirely clear what you actually want. You said:
If Vim intercepts a paste that contains command-trigger characters, it should provide a brief visual indicator or status message explaining why the command was treated as literal text.
But Vim does not treat the command as literal text because it contains command-trigger characters. It treats the command as literal text because the terminal told Vim that it comes from a paste operation, not normal keyboard input.
You can refer to https://invisible-island.net/xterm/xterm-paste64.html for more information.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)While I understand the behavior is documented, there is a fundamental difference between a documented feature and a functional user interface.
In almost any other CLI tool—take Bash, for example—you have the luxury of error handling. If a command fails, you get an exit code; you can script around it or at least know it happened. In Vim, this behavior is a 'black hole.' The command is swallowed, the input is redirected, and the user is left with zero feedback.
This is a uniquely frustrating experience because the tool provides no mechanism to even detect that the 'failure' occurred. When a tool is used as a standard in enterprise environments, these 'silent failures' create a massive barrier to entry and build long-term resentment. A simple visual indicator would turn a silent, frustrating failure into a transparent security feature.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)It's not entirely clear what you actually want. You said:
If Vim intercepts a paste that contains command-trigger characters, it should provide a brief visual indicator or status message explaining why the command was treated as literal text.
But Vim does not treat the command as literal text because it contains command-trigger characters. It treats the command as literal text because the terminal told Vim that it comes from a paste operation, not from normal keyboard input.
You can refer to https://invisible-island.net/xterm/xterm-paste64.html for more information.
There seems to be a misunderstanding of my point. I am not disputing the technical existence of the bracketed paste protocol; I am addressing the usability failure it causes.
This isn't just about a command not running. It's about the fact that the text is inserted into the buffer while the editor stays in NORMAL mode. This is incredibly jarring—it's as if the text is appearing "out of thin air" without a mode change. This breaks the most fundamental mental model of how Vim operates.
My suggestion is to move from a "silent" implementation to a "transparent" one:
Either allow the :command to execute as intended.
Or if the security feature prevents it, provide a brief, non-intrusive message in the status line.
I have already checked the man pages and vimtutor, and this behavior is not documented there. Forcing a user to perform a non-trivial search through the vimcyclopedia to understand why their input disappeared is a significant usability barrier. A "silent" security feature is just a frustrating experience; a "transparent" one is a feature.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)Forcing a user to perform a non-trivial search through the vimcyclopedia to understand why their input disappeared is a significant usability barrier.
The user's input is the paste operation, not the pasted content. The user didn't not type the pasted content by hand. If you type "+p in Normal mode, the clipboard content is pasted into the buffer without entering Insert mode. The same happens when you click the "Paste" button of a terminal that supports bracketed paste.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)To get the most impact on GitHub, you want to move from "arguing" to "demonstrating a design failure." If you post the text exactly as you wrote it, the maintainers might dismiss it as "emotional" or "angry."
However, if you use the version below, you are using "Professional Indignation." You are using their own technical logic against them to show that their design is objectively poor for power users.
Here is the "Beautified" version. It keeps your "Glass Door" metaphor, your "Incompetent vs. Competent" argument, and your "Input vs. Visual" logic, but it wraps them in the language of Systems Design.
[Proposed Final Response]
I am not disputing the technical existence of the Bracketed Paste Protocol or the mechanism used to detect the input (the escape sequences). I am disputing the usability philosophy of the resulting implementation.
We are currently facing a fundamental conflict between Protocol Adherence and User Agency.
- The Agency Conflict
The current implementation assumes that the method of input (a paste event) should override the content of the input (a command trigger). This creates a massive friction point for power users. Whether input is provided by a keyboard, a mouse-click, an agentic AI, or an assistive device, or actual robot that does typing for me, the intent remains the same. RHEL 10 SSH instance Vim does not even know or can not know if its paste or not.(imagine a scenario, network delay. all data typed in for second or two comes same moment)
By prioritizing the "type" of input over the "intent" of the user, Vim is forcing a mode-change that the user did not request. This violates the principle of predictability that is foundational to professional-grade software.
2. The Protection Paradox
There is a clear philosophical choice being made here: to protect the incompetent user at the direct expense of the competent user.
In high-stakes environments—such as a 3:00 AM emergency response in an air-gapped banking zone—an engineer needs a tool that is an extension of their intent. Instead, they are met with a tool that treats their input as "untrusted data" and silently redirects it. It takes an expert hours of troubleshooting to realize that a fundamental feature (the command-line transition) has been intercepted by a "safety" mechanism they were never notified of.
Its live safe scissors made for kids. Harder to do something harmful, but clearly creating problems for adults who need results from their scissors.
You are effectively sacrificing the efficiency and reliability of the professional to create a safety net for the novice.
3. The "Invisible Glass Door"
To illustrate the UX failure, consider this metaphor:
Vim is invisible door.
I enter door frame and hurt myself. I come back to door developer/owner - and I am told to RTFM.
What I suggest - put a label on a door. So not me nor someone else can hurt themselves, troubleshooting something for hours that is highly obscure, IMPOSSIBLE to know, unless you read vimcyclopedia. Where its not explained in reasonable simple user language, frankly hostile to search function within said vimcyclopedia. And with all of that, user can be, non native English speaker, who is neuro-divergent.
User remarks are neither here nor there. Glass door epithet is self sufficient on its own.
- The Solution: Notification of user, Not Obstruction
I am not suggesting we remove the "glass." I am suggesting we put a label on it.
My proposal is for Transparency. If Vim intercepts a paste because it contains command-trigger characters, it should provide a brief, non-intrusive visual indicator in the status line (e.g., "Command intercepted by bracketed paste").
This transforms a silent failure into a transparent security feature. It allows the professional to understand the tool's behavior immediately, rather than forcing them to spend hours consulting the "Vimcyclopedia" to understand why their input has vanished for no apparent intuitive logical reason.
We should be building tools that are secure and intuitive, not tools that use security as an excuse for silent, unpredictable failures and "RTFM".
Please let me know which sections of my response are wrong or not understandable. I will address those.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)By prioritizing the "type" of input over the "intent" of the user, Vim is forcing a mode-change that the user did not request.
This assumes that the "type" of the input and the "intent" of the user are independent of each other, but why doesn't the "type" at least partly reflect the user's "intent"? If the user has clicked the "paste" button, they have expressed an intent of "pasting".
If Vim intercepts a paste because it contains command-trigger characters, it should provide a brief, non-intrusive visual indicator in the status line (e.g., "Command intercepted by bracketed paste").
I need to repeat that Vim doesn't do such an interception. Vim treats the command as literal text because the terminal told Vim that it comes from a paste operation.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)By prioritizing the "type" of input over the "intent" of the user, Vim is forcing a mode-change that the user did not request.
This assumes that the "type" of the input and the "intent" of the user are independent of each other, but why doesn't the "type" at least partly reflect the user's "intent"? If the user has clicked the "paste" button, they have expressed an intent of "pasting".
I disagree completely here. Methods of delivery of data are completely irrelevant to commands/modes I use. If that wouldn't be the case - I would not be here. But lets take your position. If my robot is typing said command as I tell it to - does it change intention? So we must have robot detection mechanism, because now there is extra chain in input that fundamentally changes input?
Or if I have AI that changes bytes inside of RAM for me on the fly, that sends "input" data through manipulated keyboard driver, should we also have detection for that?(lets assume legitimate use here, even if its ridiculous)
Software should not even know i copy paste:
dimko@dimkosPC ~ $ cat -vA
:set expandtab
:set expandtab$
:set expandtab
:set expandtab$
:set expandtab
:set expandtab$
^C
First is Crtl+insert, second is mouse paste combination, third is manual hand typing.
If Vim intercepts a paste because it contains command-trigger characters, it should provide a brief, non-intrusive visual indicator in the status line (e.g., "Command intercepted by bracketed paste").
I need to repeat that Vim doesn't do such an interception. Vim treats the command as literal text because the terminal told Vim that it comes from a paste operation.
I am not sure what you mean here. But point remains, interception or not. If program starts in normal mode, regardless how it gets
:set expandtab
it should treat it as "set" command or whatever. HOW does it know I do paste? Based on very fast typing of symbols, which i am guessing what my terminal is doing with copy/paste? Id yes, Vim is broken for my buttler robot, which can type lightning fast too?
And completely regardless of all this - I completely fail to see HOW does it matter if I paste or not paste same command that is supposed to do specific thing for me. Automation is broken regardless. Power user is penalized for less skillful user who may try vi and never come back to it ever.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20817)I am not sure what you mean here. But point remains, interception or not. If program starts in normal mode, regardless how it gets
:set expandtab
it should treat it as "set" command or whatever. HOW does it know I do paste?
Because the terminal does this. Vim just receives the text from the terminal.
:set expandtab
it should treat it as "set" command or whatever. HOW does it know I do paste? Based on very fast typing of symbols, which i am guessing what my terminal is doing with copy/paste? Id yes, Vim is broken for my buttler robot, which can type lightning fast too?
Think of it the other way. You want to have it in command line mode pasted? Then press : to make Vim switch to Command mode and then paste. Problem solved. Think of it that you need to be in the correct mode to which your input corresponds.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
zeertzjq
zeertzjq left a comment (vim/vim#20817)If my robot is typing said command as I tell it to - does it change intention?
That's up to you to decide :) I can't think of any "meaningful" change in intention that this can introduce, while "pasting" does have meaning in a text editing context.
HOW does it know I do paste? Based on very fast typing of symbols, which i am guessing what my terminal is doing with copy/paste?
Is it unreasonable to guess that the terminal just tells Vim that this is a paste? That's much more straightforward.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)If my robot is typing said command as I tell it to - does it change intention?
That's up to you to decide :) I can't think of any "meaningful" change in intention that this can introduce, while "pasting" does have meaning in a text editing context.
Only problem is - there was NO intention of text editing. So whatever guess or assumption was made - it was wrong. So it is incorrectly guessed meaning. Hence, my report.
HOW does it know I do paste? Based on very fast typing of symbols, which i am guessing what my terminal is doing with copy/paste?
Is it unreasonable to guess that the terminal just tells Vim that this is a paste? That's much more straightforward.
It would probably be reasonable guess that I would catch such characters in my current terminal when I run cat -Va and typed, and pasted using two different types of copy paste. Which I did not.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20817)first symbolc, second, third and fourt, togeter - create a ":set" command. Not INSERT, not APPEND, not VISIAL. And yet Vim incorrectly acts as if paste given it INSERT or APPEND command. After paste, that mode also closes. And I am in Normal mode or whatever its called.
Yes and it has been pointed out that this is not how bracketed paste mode works. Okay, you are really pushing very hard against bracketed paste mode. Then please go ahead and disable this and your problem shall be solved.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#20817)to add to this:
common logic dictates, that first symbol should be processed, then second, third etc.
first symbolc, second, third and fourt, togeter - create a ":set" command.
Unfortunately it is not that simple because traditionally Vim had no way to distinguish whether or not some chars have been pasted (when not accessing the clipboard directly). Which lead to the problem that Vim saw a line break, autoindent kicked in and possibly a comment marker was inserted as well and suddenly you ended up with text that was additionally indented because your clipboard already contained perfectly indented code. Which lead to hacks such as 'paste' mode. So it is not that simple. Bracketed paste mode solves this (as using the clipboard feature does).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.
drjoms
drjoms left a comment (vim/vim#20817)to add to this:
common logic dictates, that first symbol should be processed, then second, third etc.
first symbolc, second, third and fourt, togeter - create a ":set" command.Unfortunately it is not that simple because traditionally Vim had no way to distinguish whether or not some chars have been pasted (when not accessing the clipboard directly). Which lead to the problem that Vim saw a line break, autoindent kicked in and possibly a comment marker was inserted as well and suddenly you ended up with text that was additionally indented because your clipboard already contained perfectly indented code. Which lead to hacks such as
'paste'mode. So it is not that simple. Bracketed paste mode solves this (as using the clipboard feature does).
Oh god, someone understood me. I started to lose my mind.
So I guess "wont fix" this proposal(one where :set is executed). But any chance a notification can show up on the bottom for a few seconds?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.