Error E788 when opening any help file from plugins
Check list
- [x] I have read through the README (especially F.A.Q section)
- [x] I have searched through the existing issues
Environment info
- OS
- [x] Linux
- [ ] Mac OS X
- [ ] Windows
- [ ] Others:
Version info
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Nov 22 2021 00:00:00)
Included patches: 1-3642
Modified by <[email protected]>
Compiled by <[email protected]>
Huge version with GTK3 GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
+balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
+browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand +perl/dyn +title
+channel +ipv6 +persistent_undo +toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +virtualedit
+cmdline_hist +langmap -python +visual
+cmdline_info +libcall +python3/dyn +visualextra
+comments +linebreak +quickfix +viminfo
+conceal +lispindent +reltime +vreplace
+cryptv +listcmds +rightleft +wildignore
+cscope +localmap +ruby/dyn +wildmenu
+cursorbind +lua/dyn +scrollbind +windows
+cursorshape +menu +signs +writebackup
+dialog_con_gui +mksession +smartindent +X11
+diff +modify_fname +sodium -xfontset
+digraphs +mouse +sound +xim
+dnd +mouseshape +spell +xpm
-ebcdic +mouse_dec +startuptime +xsmp_interact
+emacs_tags +mouse_gpm +statusline +xterm_clipboard
+eval -mouse_jsbterm -sun_workshop -xterm_save
+ex_extra +mouse_netterm +syntax
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -tag_old_static
system vimrc file: "/etc/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 -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/at-spi-2.0 -pthread -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DSYS_VIMRC_FILE=/etc/vimrc -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc -L. -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -L/usr/local/lib -o vim -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lSM -lICE -lXpm -lXt -lX11 -lSM -lICE -lm -lselinux -lncurses -lcanberra -lsodium -lacl -lattr -lgpm -Wl,--enable-new-dtags -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fstack-protector-strong -L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm -lcrypt -lutil -lc
Question / Problem and steps to reproduce
Error when opening any help file from plugins.
"minimap-vim.txt" [readonly] 340L, 10463B
Error detected while processing FileType Autocommands for "*"..function <SNR>37_handle_autocmd[19]..<SNR>37_buffer_enter_handler[4]..<SNR>37_source_buffer_enter_handler[2]..<SNR>37
_refresh_minimap[16]..<SNR>37_render_minimap:
line 6:
E788: Not allowed to edit another buffer now
- Install minimap.vim
- Set in
.vimrc
let g:minimap_auto_start = 1 |~
let g:minimap_auto_start_win_enter = 1
- Open any help file from any plugin, e.g.:
:h minimap

I am unable to reproduce. Is this with the most up to date minimap.vim?
I tried using the version downloaded using cargo (v0.6.1) as well as the one in the github release page (v0.6.2), but neither works.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I am also encountering this bug. I'm using neovim on Windows, version 0.6.1. This repros once, then doesn't repro again after the first hit.
I'm going to dig deeper to see if I can get a minimal repro.
OK, here's my minimal repro:
nvim version:
NVIM v0.6.1
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compiled by runneradmin@fv-az152-430
Features: -acl +iconv +tui
See ":help feature-compile"
system vimrc file: "$VIM\sysinit.vim"
fall-back for $VIM: "C:/Program Files/nvim/share/nvim"
Run :checkhealth for more info
windows version
21H2 (OS Build 19044.1586)
code-minimap version
0.6.4, installed using cargo install
minimal config (c.vim)
set rtp+=~\AppData\Local\nvim-data\site\pack\packer\opt\minimap.vim\
source ~\AppData\Local\nvim-data\site\pack\packer\opt\minimap.vim\plugin\minimap.vim
repro steps
- Start neovim with the minimal config:
nvim --clean -u c.vim - Open the minimap using
:Minimap - Open plugin documentation with
:help g:minimap_highlight - Observe error:
Error detected while processing function <SNR>23_handle_autocmd[23]..<SNR>23_buffer_enter_handler[4]..<SNR>23_source_buffer_enter_handler[2]..<SNR>23_refresh_minimap[17]..<SNR>23_render_minimap:
line 6:
E788: Not allowed to edit another buffer now
I haven't been able to trace down the cause, but these steps should hopefully produce a repro for anyone else who wants to investigate.
The error comes from when we try to navigate to the minimap window in s:render_minimap using wincmd w. Vim doesn't seem to want to let us do this, but I'm not entirely sure why. It has something to do with the state the help buffer is in when initially loaded. Subsequent attempts to open the help buffer work fine, but if you wipe that buffer with :bw! it starts breaking again.
This still only happens with third-party (plugin) help files as far as I can tell. I've tested on multiple other plugins' docs (fugitive, packer, surround, gitsigns, etc.) and all have the same behavior. I haven't been able to figure out what's different about them aside from them being third-party. Note that this doesn't happen with netrw docs, despite it technically being a plugin.
Does this only occur when using manually managed plugins? Do you normally use a plugin manager?
I usually use packer, and it occurs when using that as well. OP seems to use vim-plug, so I'm not sure it's specific to any plugin manager. These plugin managers, as far as I know, use the same basic approach for docs: adding the plugin directory to runtimepath.
The next thing I'm going to try is probably dumping as much information about the current buffer as possible right before the invocation of wincmd w. Hopefully we'll be able to see something clearly different between different types of doc files.
My worry is honestly that it's an autocmd ordering issue, though. If autocmds come in slightly differently for plugin and built-in help files, that could cause your plugin to attempt to switch buffers at an unexpected time....
Using $VIMRUNTIME/bugreport.vim, the main difference between the third-party and first-party help file cases is that third-party help files load $VIMRUNTIME/scripts.vim, while first-party ones don't. scripts.vim seems to mostly be for detecting shebang lines in files, but it's technically possible that it would mess something up.
What's maybe more interesting to me is that scripts.vim should only be loaded (as far as I can tell) if no FileType autocmd has been triggered yet for the buffer. This seems to indicate that either this FileType autocmd isn't being triggered for plugin help docs, or that it's being triggered after we hit the error. Applying $VIMRUNTIME/ftplugin/help.vim and $VIMRUNTIME/ftplugin/text.vim don't do too much, though, so I'm not sure how those specific files would be causing this....
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Also experiencing this error.