[vim/vim] Add option to disable q: (Issue #21110)

[yousefx0]

yousefx0 created an issue (vim/vim#21110)

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
A lot of times I misclick :q by q: and the cmd history window appears. This happens very often and is really annoying. The only way to disable it (as of my humble research) is by nnoremap q: <nop> or nnoremap q: :q to map it to :q however the problem with this is that when you are done recording a macro, pressing q to stop recording introduces timeoutlen delay.

Describe the solution you'd like
An option that could be set to disable q:

—
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.Message ID: <vim/vim/issues/21110@github.com>

[Christian Brabandt]

chrisbra left a comment (vim/vim#21110)

Vim executes what you type, it shouldn't guess what you meant to avoid. This doesn't belong into core, you an already disable this if you really want:

autocmd CmdwinEnter : quit

—
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.Message ID: <vim/vim/issues/21110/5361431059@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

I think the logic about the timeoutlen is fair enough. I also have disabled it with that line, as the other default is way more sensible.

—
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.Message ID: <vim/vim/issues/21110/5366575944@github.com>

[yousefx0]

yousefx0 left a comment (vim/vim#21110)

Thanks a lot for the response, appreciate you taking the time. Just to clarify though, because I don't think I explained myself that well the first time this isn't really about vim guessing what I meant, I actually agree with that philosophy.

The issue is that autocmd CmdwinEnter : quit doesn't really behave as if q: was never triggered in the first place, the window still shows up for a split second before it closes, so its more of a "hide it fast" than an actual "don't open it". You can notice this flicker pretty easily and it appears quite often.

My ohter consideration was <nowait> but it doesn't fix this either since this isn't a mapping vs mapping conflict, its a mapping vs built in command one.

So basically right now there's no actual clean way to get rid of this, either you get the flicker or you get the delay, one or the other.

What I'm getting at is, q already knows how to instantly prioritize stopping a macro recording over waiting for more of the built in q:/q//q? sequence, so what if that same kind of priority applied to user mappings (as a settable option or something) too? That way people who already remap it (which again, from what I've seen, quite a lot do, especially the q: one) wouldn't have to deal with the delay, and q:'s default behavior wouldn't have to change at all for anyone who doesn't touch it.

I think this kind of fix might be worth considering. It feels less like "messing with built in stuff" and more like fixing a gap in how q disambiguates against user maps.

—
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.Message ID: <vim/vim/issues/21110/5372982451@github.com>

[ubaldot]

ubaldot left a comment (vim/vim#21110)

What about a simple nnoremap q: <nop> ?

—
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.Message ID: <vim/vim/issues/21110/5379305133@github.com>

[Shay Hill]

ShayHill left a comment (vim/vim#21110)

What I'm getting at is, q already knows how to instantly prioritize stopping a macro recording over waiting for more of the built in q:/q//q? sequence, so what if that same kind of priority applied to user mappings (as a settable option or something) too? ... I think this kind of fix might be worth considering. It feels less like "messing with built in stuff" and more like fixing a gap in how q disambiguates against user maps.

I think you 99% don't want that, because this disambiguation means you couldn't go into command-line mode during a macro even if you wanted to (try it). That's not much of a sacrifice, but applying such rules all over the place would make things frustrating.

—
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.Message ID: <vim/vim/issues/21110/5379965299@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

I am wholeheartedly backing the notion that CTRL-F is fine, q: is by word of mouth the most unmapped mapping 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.Message ID: <vim/vim/issues/21110/5380782286@github.com>

[Houl]

Houl left a comment (vim/vim#21110)

You can use a mapping (with v8.1.0020 or newer).

noremap <expr><script> q reg_recording()!='' ? 'q' : '<SID>__qmode__'
noremap <SID>__qmode__: :<C-U>q
noremap <SID>__qmode__  q

This corrects q: into :q and should still keep macro recording working.

—
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.Message ID: <vim/vim/issues/21110/5387259092@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

Appreciate the effort @Houl however.. Its +4 lines to fix an issue that shouldn't have ever existed in the first place. There's a reason why the message was added to that window.

I don't believe all the hassle this mapping brings is worth justifying its default mapping.

—
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.Message ID: <vim/vim/issues/21110/5434395187@github.com>

[Nick Jensen]

nickspoons left a comment (vim/vim#21110)

...and one of the most common requests for how to unmap in #vim

This is not true. I just searched through the history since 2022 and can't find any instances of people asking for this.

—
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.Message ID: <vim/vim/issues/21110/5445910488@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

...and one of the most common requests for how to unmap in #vim

This is not true. I just searched through my libera #vim logs since 2022 and can't find any instances of people asking how to unmap q:.

Would you be sad if it was not default?

—
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.Message ID: <vim/vim/issues/21110/5446752126@github.com>

[knil]

knil201 left a comment (vim/vim#21110)

...and one of the most common requests for how to unmap in #vim

This is not true. I just searched through my libera #vim logs since 2022 and can't find any instances of people asking how to unmap q:.

A quick google search shows many links on stackoverflow, reddit, or other sites where people ask for ways to disable/remap q: and I'm one of the people who was searching to find a solution but didn't open an issue and I am still bothered with q:.

—
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.Message ID: <vim/vim/issues/21110/5447127999@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

chris argument is fine, but it does not make it less of a sadistic/schadenfreude mapping imho.

Idk if all those likes are from a place of "don't change it cuz its been like that forever" but this mapping is uniquely in the way.

I asked around everyone I talked to the last few days I know who use vim and they all laughed when they heard this mention mapping.

We've all been knocked in the head by that one.

—
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.Message ID: <vim/vim/issues/21110/5447632106@github.com>

[dkearns]

dkearns left a comment (vim/vim#21110)

If you can't type you're going to have a very rough time using Vim proficiently.

I asked around everyone I talked to the last few days I know who use vim and they all laughed when they heard this mapping mentioned.

All of them? Every last one? On average was it a good belly laugh, a mild chuckle, or a cruel snigger?

We've all been knocked in the head by that one at some point,

Not once have I accidentally opened the command-line window. I do open it intentionally though, it's almost as easy as quitting. You just have to swap the...never mind.

keeping it is pure sadism.

Having to close a small window rises to the level of "sadism"? Because now you have to close two windows?
Do you get trapped in an almost endless cycle of opening and closing the command-line window, only rarely exiting Vim itself? Honestly, I'd think you'd be thankful for the extra practice.

Why not argue for the banning of any command that when transpositionally typed executes another? At least q: shouldn't ruin anyone's day like @: might.

—
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.Message ID: <vim/vim/issues/21110/5451914060@github.com>

[yousefx0]

yousefx0 left a comment (vim/vim#21110)

I honestly don't understand the pushback against even looking for a solution and instead blaming the user, I mean it is true that the user is the one who hit q: but anyways aside from the q: command specifically, it is undeniable and kind of disappointing that vim has a limitation in mapping q:/q?/q/ without trade offs despite that one of vim's main goals is customizability and the user's ability to customize and tweak the config to fit his own needs and liking.

—
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.Message ID: <vim/vim/issues/21110/5452155686@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

Surprise.. q: is easy to hit, as :q is also one of the most used commands.

Lets make it a donate goal. I fear you will have to give up the mapping, because there are more people who will gladly donate to get rid of it than keep 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.Message ID: <vim/vim/issues/21110/5454178682@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

Flat out rejecting the issue is what makes me care about it, however I didn't intend to come off like that as you are right, I agree and apologize.

However - those who flat out reject this issue. Please consider the alternative that 4 lines of undoing this with a potentially flaky fix could be replaced by defaulting to a more flexible, less opinionated way that addresses the issue and recognizes that there is roughly half or more of the users who don't prefer it.

Already I think adding the You've discovered the cmdline window is an anti-pattern that just flat out rejects the idea that it gets in the way..

If you provided it via a configure flag would you trust your distro to not disable it, at cost of divering from upstream? I would not, because I would think it was a sane thing to do given how it clashes with :q and gets in the way.

—
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.Message ID: <vim/vim/issues/21110/5455831222@github.com>

[Shougo]

Shougo left a comment (vim/vim#21110)

I understand that the mapping is unnecessary for many users. However, simply deleting it outright isn't feasible due to compatibility concerns.
This is because the plugin might be using that mapping internally to open the command-line window.
Making it an option might be a good idea, but I’m not entirely convinced, as it would require the plugin to check whether the option is enabled.
Honestly, I think the best approach is for users to handle it via their own mappings.

—
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.Message ID: <vim/vim/issues/21110/5460161009@github.com>

[OranGe-66]

OranGe-66 left a comment (vim/vim#21110)

Seems fair enough if viable I guess.

—
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.Message ID: <vim/vim/issues/21110/5465644480@github.com>

[Shougo]

Shougo left a comment (vim/vim#21110)

@yousefx0 Could you explain using a concrete configuration example?

—
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.Message ID: <vim/vim/issues/21110/5466202804@github.com>

[yousefx0]

yousefx0 left a comment (vim/vim#21110)

Maybe something like set endmacropriority=1, where the default value is 0 and the accepted value could be:

• less than or equal zero : pressing q during a macro record enables the delay for user-defined maps that start with q (current Vim behavior).
• positive : pressing q during a macro record instantly ends macro recording even if there is a user defined map that starts with q.

—
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.Message ID: <vim/vim/issues/21110/5466423406@github.com>

[ubaldot]

ubaldot left a comment (vim/vim#21110)

I am here only to say that I am against such a change proposal.

Also, the scientific basis of "I asked around" & Co. used to justify the change, further reinforce my position.

—
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.Message ID: <vim/vim/issues/21110/5470138502@github.com>

[knil]

knil201 left a comment (vim/vim#21110)

No offense here but your position doesn't look like it was reinforced in the first place with my respect. You just showed denial without a reason nor suggesting an actual solution alternative (unless you are just expressing your opinion with no reason in mind). The option suggested is fine if it is doable, it seems to actually solve the issue and satisfy everyone without affecting default vim behavior. Being against it in my opinion is being against vim's philosophy of doing customizations and remaps to fit one's needs. Also a quick google search would bring up many links to stackoverflow, reddit, and even medium blogs where people are discussing about how to disable/remap q:.

—
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.Message ID: <vim/vim/issues/21110/5470718060@github.com>

[Christian Brabandt]

chrisbra left a comment (vim/vim#21110)

You can use a mapping (with v8.1.0020 or newer).

noremap <expr><script> q reg_recording()!='' ? 'q' : '<SID>__qmode__'
ounmap q|sunmap q
noremap <SID>__qmode__: :<C-U>q
noremap <SID>__qmode__  q

This corrects q: into :q and should still keep macro recording working.

Nice. I'll put that into the documentation, so users can copy and paste it into their vimrc.

—
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.Message ID: <vim/vim/issues/21110/5471001087@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

@ubaldot make a poll on reddit or make a biased "scientific" research. Plenty of shitty science out there. That mapping is without a doubt the top criticised mapping - sad that people stand in line to enforce this sadism on regular people.

—
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.Message ID: <vim/vim/issues/21110/5480128979@github.com>

[Shougo]

Shougo left a comment (vim/vim#21110)

I agree that the proposed mapping is a workaround rather than a fundamental fix. However, I am not sure that this particular issue justifies adding a new option such as endmacropriority.

The underlying problem is not really specific to q:. It is the lack of a general mechanism for resolving conflicts between built-in key sequences or special input handling and user-defined mappings. If Vim were to address that problem in a general and reusable way, I think it would be worth considering.

For the specific q: case, however, the documented workaround seems like a reasonable compromise. It preserves the current default behavior, does not remove the built-in command, and only affects users who explicitly choose to override it. The maintenance and specification costs of adding a new option may be disproportionate to the scope of this issue.

—
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.Message ID: <vim/vim/issues/21110/5486808082@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

@Shougo as I read your suggestion it sounded like you wanted to add callables to replicate the builtin functionality, so it indeed could be mapped and unmapped cleanly - then no "macro priority" is needed, because keytimeout wouldn't be triggered if not applied - correct me if I'm wrong? Then Vim can still retain defaults, all that changes is that it is decoupled, as it should be.

—
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.Message ID: <vim/vim/issues/21110/5489071675@github.com>

[Shougo]

Shougo left a comment (vim/vim#21110)

Currently, the handling of : after q is built into the implementation of q itself, rather than being provided as an ordinary default mapping. Since q takes a register as an operand, this is probably related to the way the command is parsed, but it does make the behavior difficult to change or override cleanly.

Separating the command-line-window functionality from the q command, and exposing it through callable built-ins that can be used by default mappings, would make the design more flexible. Then q:, q/, and q? could remain the defaults while still being cleanly unmapped or replaced by users.

This seems more general and architecturally cleaner than adding an option specifically for macro priority, although it may require a larger change to Vim's command/input handling.

—
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.Message ID: <vim/vim/issues/21110/5489509221@github.com>

[dezza]

dezza left a comment (vim/vim#21110)

That sounds like reasonable decoupling to me.

—
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.Message ID: <vim/vim/issues/21110/5489518843@github.com>

[atusy-attmcojp]

atusy-attmcojp left a comment (vim/vim#21110)

Here's a trick

nnoremap q <plug>(q)
nnoremap <plug>(q) <cmd><cr>q
nnoremap <plug>(q): <nop>

—
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.Message ID: <vim/vim/issues/21110/5491679835@github.com>

[OranGe-66]

OranGe-66 left a comment (vim/vim#21110)

Currently, the handling of : after q is built into the implementation of q itself, rather than being provided as an ordinary default mapping. Since q takes a register as an operand, this is probably related to the way the command is parsed, but it does make the behavior difficult to change or override cleanly.

Separating the command-line-window functionality from the q command, and exposing it through callable built-ins that can be used by default mappings, would make the design more flexible. Then q:, q/, and q? could remain the defaults while still being cleanly unmapped or replaced by users.

This seems more general and architecturally cleaner than adding an option specifically for macro priority, although it may require a larger change to Vim's command/input handling.

I think that might be a good solution too.

So now there are two real solutions on the table. Some feedback is needed here. In my opinion, the 4 line fix shouldn't be documented as the approved method. It's a disgrace to be the "official" fix and in my honest opinion, this issue should be re-opened. @chrisbra Please consider re-opening the issue and further discussion about implementing a real solution.

—
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.Message ID: <vim/vim/issues/21110/5503892170@github.com>

[dkearns]

dkearns left a comment (vim/vim#21110)

Telling someone their decision is a disgrace then asking them for something is an interesting approach.

—
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.Message ID: <vim/vim/issues/21110/5504498348@github.com>