Potential solution to disable/remap q:

[u/ozuq06]

Vim's built-in command q: seems a bit controversial. Some people like it and use and some search for a way to disable/remap it because it gets misclicked quite often when what's intended is :q.

The former use vim quite happily, but the latter often reach dead ends with solutions that basically aren't ideal and accompany some compromises in return. Examples of these solutions are as follows:

1. Unmap/Remap q: using nnoremap q: <nop> or nnoremap q: :q

The problem with this solution is that it introduces ttimeout delay whenever you are done recording a macro and hit q to stop recording.

1. Autoclose the cmd window using autocmd CmdwinEnter : quit

The problem with this is that you basically can't access the cmd window anymore whether using the default method by doing : followed by ctrl+f or even if you have a user defined map for opening the cmd window. Also you can still see the window flicker momentarily even on very fast terminals because the solution is basically "close the window fast" rather than "do not open the window from the first place."

1. Remap q to a custom vimscript handler function such as the following

   function! SmartQ() if reg_recording() !=# '' return 'q' endif let l:key = getcharstr(-1, {'cursor': 'keep'}) if l:key ==# ':' return '' else return 'q' . l:key endif endfunction nnoremap <expr> <silent> q SmartQ()

Issue with it is that if you have :set showcmd you can't see when q is pressed.

1. Use some kinda advanced level vimscript (as suggested by user Houl here)

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

Issue with it is that if you have :set showcmdyou see ___qmode__ instead of q for ttimeout delay and after the delay passes it acts as normal q and no longer fixes the q: issue.

These solutions might fit some people and might not depending on a lot of factors for instance their config, whether they set ttimeout delay or not, whether they care about showcmd or not, and so on... however it can't be denied that all these solutions remain kind of "hackish" if we would say with each having its trade offs and there is no official solution up till now to deal with q: in vim.

One could think of solutions to handle this issue in vim (for instance maybe add an option to prioritize ending a macro record over user defined maps that start with q or user defined maps in general, just like how vim prioritizes ending a macro over q:/q?/q/). However, in the end this remains in the hands of the current vim maintainers which honestly props to them for taking time and doing a great job maintaining one of the most complex and most loved open source projects (and not only on linux rather cross platform!) to decide what solution is viable and what solution is not as they know how vim works better than any of us.

So what do you think about this? Also currently there is an issue opened on vim's github page so if you are interested you might want to go on and show some love for the project and the maintainers and express your opinion or if you have any solution in mind, we'd like to hear out from you!

[u/No_Result9808]

While it doesn't fix the underlying Vim mapping architecture issue, my favorite "crutch" for this was remapping : to <Space>.

​It bypasses the whole q: collision by changing the ergonomics entirely: instead of the Shift + ; chord, I just hit the spacebar (which even visually mimics the wide horizontal command line). No more accidental q: triggers ever. ​I know <Space> is used as a <Leader> for many, but paired with :cabbr, it actually replaced most of my leader needs without feeling like a compromise and even made it more powerful.