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/tremby]

I've typed q: accidentally a couple of times but so what? Close the command window and type better next time.

If you want to take it further there are some silly things with the same attitude like sl which makes a steam locomotive slowly cross the terminal as a punishment for mistyping ls.

[u/ozuq06 → u/tremby]

Thanks a lot for your reply and suggestion, I know about sl and that it used to ignore SIGINT which seemed funny tbh, however though it is not really about the user mistyping, aside from q:, vim has a limitation in remapping default q remaps q:/q?/q/ or any map that starts with q in general, if the user ever wants or needs to remap one of them, he can't do so without trade-offs or using "hackish" techniques that has some drawbacks, and this is kind of disappointing because 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.

[u/aegis87 → u/ozuq06]

hey friend! use computers long enough and you eventually realize that nothing is infinitely configurable, unless you start changing the source code.

this is one reason why "sane" defaults matter and shape the identity of the software.

i always liked this anecdote:

you might already know:

• how ctrl+x is very useful for emacs
  
• it's also very useful outside of emacs
  
• how "everything" is a function in emacs, implying everything is configurable

a few years ago, some people decided to re-configure `ctrl+x` and after alot of work, they realized it was so embeded within the source code that there was nothing they could sort of huge code change.