[vim/vim] autocmd from vim8script acting strange when other vim9script plugin is loaded. (Issue #9916)
kohnish
Steps to reproduce
This is an example output when I have both vim-signify and lsp loaded via packadd!.
https://github.com/mhinz/vim-signify
https://github.com/yegappan/lsp
The issue doesn't happen on 8.2.4337 but on 8.2.4501
Error detected while processing CursorHold Autocommands for "<buffer=2>"..function sy#start[66]..sy#repo#get_diff:
line 29:
E700: Unknown function: s:callback_vim_close
Steps to reproduce:
TBA.
Expected behaviour
No error output from other plugins.
Version of Vim
8.2.4501
Environment
Fedora 35
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
Could you check whether the regression was caused by one of these commits?
- 8.2.4360 Vim9: allowing use of "s:" leads to inconsistencies
- 8.2.4371 Vim9: can create a script variable from a legacy function
- 8.2.4416 Vim9: using a script-local function requires using "s:"
- 8.2.4446 Vim9: cannot refer to a global function like a local one
- 8.2.4447 Vim9: can still use s:var in a compiled function
- 8.2.4499 Vim9: at the script level declarations leak to next block
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
It might be the same issue as #9820
The latter is reportedly caused by a regression introduced in patch 8.2.4429.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
It started happen with 8.2.4446 !
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Maybe it's only this particular lsp plugin issue, I'm also using locally patched version.
I'll update the step to reproduce as soon as I come up with a simple example script.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
I can't reproduce it with example scripts. For now I updated the issue how I can trigger the bug with my vim9 plugin(vim9-fuzzy) and vim-signify.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
For now I updated the issue how I can trigger the bug with my vim9 plugin(vim9-fuzzy) and vim-signify.
I can't go beyond this command:
$ make -j install
It terminates with this error:
/usr/bin/ld: fs.c:(.text+0x32a): undefined reference to `dlerror'
collect2: error: ld returned 1 exit status
make[2]: *** [native/app/CMakeFiles/vim9-fuzzy.dir/build.make:160: native/app/vim9-fuzzy] Error 1
make[1]: *** [CMakeFiles/Makefile2:209: native/app/CMakeFiles/vim9-fuzzy.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
Same issue in a docker container:
$ sudo --preserve-env docker run --interactive=true --tty=true --rm=true ubuntu:latest
$ apt update
$ apt install git cmake
...
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Note that patch 8.2.4429 fixed a problem, using the wrong script to find a function.
It is possible that the script depended on the wrong way it worked before the patch.
Perhaps it can be fixed by changing the plugin.
Is there a way to reproduce without installing plugins? If this actually is a bug, we need that anyway to be able to add a regression test.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
I pushed the potential fix for my plugin but adding libuv1-dev pkg-config and removing -DBUILD_STATIC=ON might also help. @lacygoill
Yeah, I'll try to come up with simpler way to reproduce this. but it's pretty hard so far even with my broken plugin. lsp is easier to reproduce but it's harder to setup.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
I pushed the potential fix for my plugin
I can confirm that it fixes the error. However, I still can't reproduce the issue. Note that I've slightly updated your commands as I don't want to mess with my own config. I work in a temporary directory outside my $HOME:
mkdir -p ~/.vim/pack/test/start
→
cd /run/user/1000/tmp/
mkdir -p ./.vim/pack/test/start
cd ~/.vim/pack/test/start
→
cd ./.vim/pack/test/start
...
But that should not alter the results.
In any case, there are still issues in the given steps. For example, you said you were using :packadd!:
This is an example output when I have both vim-signify and lsp loaded via packadd! in vim9script vimrc.
But then, you clone the plugins in a start/ subdirectory:
$ mkdir -p ~/.vim/pack/test/start
packadd! can't find them there; instead, they need to be under an opt/ subdirectory. After moving the plugins over there, the code work fine.
Also, you didn't show the contents of your minimal vimrc. Here is mine:
vim9script
&packpath = '/run/user/1000/tmp/.vim/'
packadd! vim-signify
packadd! vim9-fuzzy
Maybe I've missed something, and I need to more tests, I don't know.
In the meantime, I suggest you re-read all the reported steps and make sure nothing is missing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
lacygoill
However, I still can't reproduce the issue.
When I try to open the configure file in the second Vim instance, I get this warning:
Found a swap file by the name ".configure.swp"
owned by: lgc dated: Wed Mar 09 20:44:16 2022
file name: /run/user/1000/tmp/vim/configure
modified: no
user name: lgc host name: ubuntu
process ID: 143748 (STILL RUNNING)
While opening file "configure"
dated: Wed Mar 09 20:27:00 2022
(1) Another program may be editing the same file. If this is the case,
be careful not to end up with two different instances of the same
file when making changes. Quit, or continue with caution.
(2) An edit session for this file crashed.
If this is the case, use ":recover" or "vim -r configure"
to recover the changes (see ":help recovery").
If you did this already, delete the swap file ".configure.swp"
to avoid this message.
Swap file ".configure.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (A)bort:
Do you get the same error? How do you get around it? Do you have a SwapExists autocmd?
Then, if I press O to open the file in read-only mode, or E to edit it, I get this error:
Error detected while processing function <SNR>30_StartWindow[3]..<SNR>30_BlockInput[123]..<SNR>30_FocusOrOpen:
line 8:
E325: ATTENTION
It comes from this line:
execute "edit " .. filename
Inside this function:
FocusOrOpen()
Inside this file:
.vim/pack/test/opt/vim9-fuzzy/plugin/window_handler.vim
Afterward, I don't get the reported E700 error.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Sorry, the example I prepared uses start dir, so no need for packadd.
I was working on fedora container with empty vimrc when I was testing the step. The issue happens both 'start' and 'opt' setup.
Thank you all for paying your attention for this.
I'm working on autocmd, job_start mixture example. A simple script didn't cause the issue. (vim-signify installed with simpler vim9 test plugin for example)
Also when the issue happens, the vim8 plugin stops working, not the vim9 one(I this case lsp or vim9-fuzzy). I also reproduced the error with git-gutter plugin mixture with lsp.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Yeah. The same. You have to try again after the error happens. And then you should see error from vim-signify. First error from vim9-fuzzy is expected, which I will fix after this issue was resolved.
Seem like a good error to reproduce the real issue here.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
bfrg
I encountered similar errors without using the above plugins. On my computer it happened with a function from vim-commentary. Unfortunately, I haven't been able to reproduce it with a minimal test yet. The errors seemed to have started showing up after :source % a vim9script file that contained a few errors. Eventually when I pressed gcc to comment the current line, the errors started showing up.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
You have to try again after the error happens. And then you should see error from vim-signify
This is what I tried so far, without success (i.e. no E700):
First error from vim9-fuzzy is expected, which I will fix after this issue was resolved.
You might want the :noswapfile modifier.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Looks like you're doing exactly what I've described. :(
Thank you for taking time taking the video.
In my case, On empty text file, I see error from vim-signify.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Further scoping the issue...
v8.2.4428...v8.2.4429
Commenting out line:1970~1983 in src/userfunc.c solves the issue. Bringing it to the last is also fine.
I have no idea about vim source code, but I see the comment like, maybe from there, we can reverse-generate test vimscript to make sure this issue doesn't happen?
// Find autoload function if this is an autoload script.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Moving to the last, I meant a patch like this.
The current master returns find_func_with_prefix when it's NULL in find_func_with_sid, while this one is probably returning NULL.
// Find autoload function if this is an autoload script.
func = find_func_with_prefix(name[0] == 's' && name[1] == ':' ? name + 2 : name, current_sctx.sc_sid);
if ((flags & FFED_IS_GLOBAL) == 0 && in_vim9script() && STRNCMP(name, "<SNR>", 5) == 0) {
char_u *p = name + 5;
long sid;
// printable "<SNR>123_Name" form
sid = getdigits(&p);
if (*p == '_') {
func = find_func_with_sid(p + 1, (int)sid);
if (func != NULL)
return func;
}
}
return func;
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
lacygoill
I've reduced the issue to this code:
vim9script var lines =<< trim END function LegacyJob() call job_start(':', {'close_cb': function('s:close_cb')}) endfunction function s:close_cb(...) endfunction END lines->writefile('/tmp/legacy.vim') source /tmp/legacy.vim autocmd BufRead * g:LegacyJob() autocmd BufEnter * g:LegacyJob() split /tmp/foo bdelete []->writefile('/tmp/bar') []->writefile('/tmp/.bar.swp') edit /tmp/bar
E325: ATTENTION
E117: Unknown function: <SNR>2_close_cb
E325 is expected but not E117. To get the same error as the OP, you need to press space until you get this prompt:
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:
Then, press o or e to open the file:
E700: Unknown function: s:close_cb
It's clearly a bug, because the E117 message tells us that there is no close_cb() function local the script whose ID is 2. The only way that could be true is if somehow the ID of the legacy.vim script was not 2. But it is:
:scriptnames
1: /proc/214678/fd/17
2: /tmp/legacy.vim
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
i think/guess that just a similar situation like #9910 which missed/forgot the limitation that s: refactor just fit for vim9, but now those legacy callback func within function() became problem.
specially if there vim9 script plugins and legacy plugins (which had callback func within function()) in your vimrc.
// local workaround is easy, but just somehow did not know what exactly happened...
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
I'm not sure what the next step is. The test script is the smallest it can get.
Obviously this check is unnecessary and I prefer it to be removed to avoid accumulating the releases with this bug because vim9script is quite useless for me now.
However, it seems there is something very wrong going on that we are getting vim8 function in in_vim9script .
Can you give us some help? @brammool
userfunc.c:1975
if (in_vim9script() && STRNCMP(name, "<SNR>", 5) == 0)
{
char_u *p = name + 5;
long sid;
// printable "<SNR>123_Name" form
sid = getdigits(&p);
if (*p == '_')
{
func = find_func_with_sid(p + 1, (int)sid);
if (func != NULL)
return func;
}
}
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
kohnish
Awesome! Thank you all for the help.
—
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.