[vim/vim] Vim9 vimrcs don't give correct `cpo` values to plugin files (Issue #10772)
Olivia (Zoe)
Steps to reproduce
TL;DR;
- Copy the vim9 vimrc from the long version (first code block) to
~/vim9.vimrc - Create a directory
demoin~/.vim/pack/vendor/start/ - Create a directory
pluginin the recently createddemodirectory - Create a file
MyFile.vim, copy in the second code block from the long version
The same problem happens if a proper plugin manager is used, such as vim-plug.
Long version
Given the following relatively minimal vimrc:
vim9script set encoding=utf-8 set fileencoding=utf-8 set termencoding=utf-8 set nocompatible filetype off echo 'CPO, vimrc' &cpo
and a dummy (in my example, ~/.vim/pack/vendor/start/) project with a plugin file MyFile.vim:
echo &cpo fun s:func() echo 'hi' let x = { \ 'x': 'y' \ } endfun fun MyFile#vim8() call s:func() return 42 endfun
I get some extremely weird output:
❯ vim -u vim9.vimrc +qa
# Editor's note: this is the default value
CPO, vimrc aABceFs
# Editor's note, I have no idea what this utter garbage is:
aAbBcCdDeEfFgHiIjJkKlLmMnoOpPqrRsStuvwWxXyZ$!%*-+<>;
This weird behavior causes syntax errors that I initially believed to be the files parsed as Vim9, but I don't believe that's the case, considering it doesn't respond to function with an error, which it would be in vim9.
Also worth noting that Vim9 is the component that somehow breaks everything. This vimrc does not fail:
set encoding=utf-8 set fileencoding=utf-8 set termencoding=utf-8 set nocompatible filetype off echo 'CPO, vimrc' &cpo
Yielding:
# Note; vim9.vimrc has been changed to legacy vimscript prior to command execution because it was faster to edit rather than copying
# and editing when I've made a lot of changes to reduce the problem
❯ vim -u vim9.vimrc +qa
CPO, vimrc aABceFs
aABceFs
... which is what I expected. Worth noting that, aside converting to legacy vimscript, these two vimrcs are identical. This was initially reported at junegunn/vim-plug (because that's where I observed the issue), where I used a more complicated vimrc requiring a bit of a rewrite to be vim9-compatible around function calls. Here, the only difference between the two is removing vim9script, and the behavior change in cpo is still present.
In early research, I ran into problems with my own plugin, as well as startify, and both these had a ton of syntax errors. The syntax errors are exclusively the consequence of cpo being a complete mess. I initially assumed the files were incorrectly interpreted as vim9script, but this isn't the case. Worth noting that the syntax errors in this example aren't tripped, because the code is in a set of functions, neither of which are executed. CPO being completely screwed results in line continuations being disabled, which is in line with :h E10, which I observed in the two plugins that prompted this issue.
vim-startify in particular yielded problems in an autoload file; this autoload file is loaded via the plugin file, as a consequence of cpo cascading down into autoload files loaded by the plugin with the bad cpo setting.
While I haven't made an example for this, it's trivial to prove it isn't a surface level Vim9 issue; converting MyFile to an autoload file instead of a plugin file, and adding echo MyFile#vim8() to the example vim9 vimrc prints the right cpoptions, and everything runs as expected. This means it is clearly an issue when the plugin files themselves are loaded, and not an issue with vim9 or the converted vim9 vimrc
I have also not tested whether the issue is present with vim9 plugins; the tests here are purely for a vim9 vimrc with legacy vimscript plugins. The issue may be present in vim9 plugins as well, but the type of script is, in theory, irrelevant. it happens when the plugin files are loaded, so unless the vim9script keyword explicitly sets cpo, they're most likely going to suffer from the same problem caused by some plugin loading component.
And finally, I haven't tested if cpo is the only variable that doesn't get "moved" properly. This may affect more, or all, or of course just &cpo. It's just painfully obvious when &cpo is wrong because of the syntax errors that ensue from it being incorrectly set.
Expected behaviour
&cpo should retain the value it has in the vimrc, rather than the garbage it currently yields.
Version of Vim
9.0.55
Environment
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jul 17 2022 18:41:43)
Included patches: 1-55
Compiled by Olivia
Huge version with GTK2 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 +title
+channel +ipv6 +persistent_undo +toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3 +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap +ruby +wildignore
+cursorbind +lua +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con_gui +mksession +smartindent +writebackup
+diff +modify_fname -sodium +X11
+digraphs +mouse -sound -xfontset
+dnd +mouseshape +spell +xim
-ebcdic +mouse_dec +startuptime +xpm
+emacs_tags -mouse_gpm +statusline +xsmp_interact
+eval -mouse_jsbterm -sun_workshop +xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi -mouse_sysmouse -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/local/share/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/arm-linux-gnueabihf/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/libmount -I/usr/include/blkid -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2 -D_REENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang -L. -Wl,-z,relro -Wl,-z,now -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -L/usr/local/lib -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 -lselinux -lrt -ldl -L/usr/lib/arm-linux-gnueabihf -lluajit-5.1 -Wl,-E -fstack-protector-strong -L/usr/local/lib -L/usr/lib/arm-linux-gnueabihf/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt -L/opt/upm-active/lib/python3.10/config-3.10-arm-linux-gnueabihf -lpython3.10 -lcrypt -lpthread -ldl -lutil -lm -lm -lruby-2.5 -lpthread -lgmp -ldl -lcrypt -lm -L/usr/lib
OS: Raspbian, based debian 10 (buster)
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
Editor's note, I have no idea what this utter garbage is:
aAbBcCdDeEfFgHiIjJkKlLmMnoOpPqrRsStuvwWxXyZ$!%*-+<>;
It's the Vi default value, which sets most (if not all) the flags.
If you start in debug mode ($ vim -u vim9.vimrc -D), you can see that the value of 'cpoptions' is reset right after sourcing the vimrc.
line 10: End of sourced file
>echo &cpo
aABceFs
>step
/usr/local/share/vim/vim90/plugin/getscriptPlugin.vim
line 16: if exists("g:loaded_getscriptPlugin")
>echo &cpo
aAbBcCdDeEfFgHiIjJkKlLmMnoOpPqrRsStuvwWxXyZ$!%*-+<>;
In the past, I think there was a similar issue with a regular vimrc (one whose location is not specified by -u).
It was fixed in patch 8.2.3901. Not sure, but the solution for the current issue might be identical:
An alternative could be that if 'cpoptions' was changed in the Vim9 script file, then it is not restored.
It would just need to be extended from vimrcs whose location is hard-coded, to vimrcs whose location is arbitrarily specified via -u.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Olivia (Zoe)
Hm, that is interesting. Checked with the default vimrc location, and that does indeed behave correctly. Explains why the report hasn't emerged yet I suppose; I used -u to start the migration without touching my main vimrc. Complete breakage would've been easier to detect.
The solution does sound like it's identical though, at least from the other bug report. At least it hasn't regressed to break the default .vimrc location
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
If you use -u, Vim starts in compatible mode. See :help -u.
You can use -N together.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Olivia (Zoe)
Hm, so -u fully ignores set nocompatible in the loaded file? How come the legacy vimscript vimrc doesn't do the same thing?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
Oh, I missed that line. There might be something wrong with vim9script initialization.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Olivia (Zoe)
Probably. -N does still work to be fair, so it sounds reasonable for it to be initialization-related somehow.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.