vim goes to 100% CPU usage while recording macro like this
Desciption:
qqq@qqq@@q@q (vim unresponsive and goes to 100% on cpu core)Vim version:
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 18 2020 18:29:15)
Included patches: 1-1453
Modified by [email protected]
Compiled by [email protected]
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +farsi +mouse_sgr -tag_any_white
+arabic +file_in_path -mouse_sysmouse +tcl
+autocmd +find_in_path +mouse_urxvt +termguicolors
-autoservername +float +mouse_xterm +terminal
+balloon_eval +folding +multi_byte +terminfo
+balloon_eval_term -footer +multi_lang +termresponse
+browse +fork() -mzscheme +textobjects
++builtin_terms +gettext +netbeans_intg +timers
+byte_offset -hangul_input +num64 +title
+channel +iconv +packages +toolbar
+cindent +insert_expand +path_extra +user_commands
+clientserver +job +perl +vertsplit
+clipboard +jumplist +persistent_undo +virtualedit
+cmdline_compl +keymap +postscript +visual
+cmdline_hist +lambda +printer +visualextra
+cmdline_info +langmap +profile +viminfo
+comments +libcall -python +vreplace
+conceal +linebreak +python3 +wildignore
+cryptv +lispindent +quickfix +wildmenu
+cscope +listcmds +reltime +windows
+cursorbind +localmap +rightleft +writebackup
+cursorshape +lua +ruby +X11
+dialog_con_gui +menu +scrollbind -xfontset
+diff +mksession +signs +xim
+digraphs +modify_fname +smartindent +xpm
+dnd +mouse +startuptime +xsmp_interact
-ebcdic +mouseshape +statusline +xterm_clipboard
+emacs_tags +mouse_dec -sun_workshop -xterm_save
+eval +mouse_gpm +syntax
+ex_extra -mouse_jsbterm +tag_binary
+extra_search +mouse_netterm +tag_old_static
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/libpng16 -Wdate-time -g -O2 -fdebug-prefix-map=/build/vim-dfCUyu/vim-8.0.1453=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.26/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python3.6/config-3.6m-x86_64-linux-gnu -lpython3.6m -lpthread -ldl -lutil -lm -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lm -lruby-2.5 -lpthread -lgmp -ldl -lcrypt -lm
Your Vim 8.0.1453 was compiled by the Debian maintainers on 18 March 2020, but that source actually goes back to 2 February 2018. The latest source as of this writing is 8.2.705. Maybe the problem has been fixed in the intervening two years, or maybe not, but do you think you could try a more recent version of Vim?
See among others:
Best regards,
Tony.
P.S. On rereading the question, I think the 100% CPU is normal.
You recorded something into register q then stopped recording. Then you replaced the recording by another one which in effect says: "Play back the latest recorded macro". So you hit @q and vim finds there @@ which tells it to play the latest macro, which is @@ which tells it to play the latest macro which is @@ which tells it to play the latest macro…
Have you ever heard the story of the record with a scratch in it, ratch in it, ratch in it, ratch in it, ratch in it, ratch in it?
Best regards,
Tony.
Most helpful comment
P.S. On rereading the question, I think the 100% CPU is normal.
You recorded something into register q then stopped recording. Then you replaced the recording by another one which in effect says: "Play back the latest recorded macro". So you hit @q and vim finds there @@ which tells it to play the latest macro, which is @@ which tells it to play the latest macro which is @@ which tells it to play the latest macro…
Have you ever heard the story of the record with a scratch in it, ratch in it, ratch in it, ratch in it, ratch in it, ratch in it?
Best regards,
Tony.