I'm not sure it can always be used as a workaround

Because the | command also count those virtual cells. Same thing for the \%v atom. More generally, no matter how 'wrap', 'linebreak', 'breakindent', ... are set, |/\%v always seem to agree with virtcol(). IOW, if you intend to use the position in a 123| command or \%123v atom, you'll still want virtcol().

I'm not sure it can always be used as a workaround, but since the patch 8.2.2324, Vim provides the charcol() function which gives positions in terms of character index:

vim9script
lefta :25vnew
setl wrap lbr
setline(1, 'the quick brown fox jumps over the lazy dog')
norm! 19l
echom virtcol('.')
norm! 029l
echom virtcol('.')

25
35

vim9script
lefta :25vnew
setl wrap lbr
setline(1, 'the quick brown fox jumps over the lazy dog')
norm! 19l
echom charcol('.')
norm! 029l
echom charcol('.')

20
30

Notice that in the first snippet, the 5 virtual cells after the "x" in "fox" are counted when giving the column position of the cursor:

                    there is nothing there;
                    these are not spaces in the text;
                    and yet "virtcol()" count them
                    v---v
the quick brown fox      |
jumps over the lazy dog  |

But not in the second snippet.

Describe the bug

In Vim9 script, passing a legacy lambda as an argument to a :def function makes Vim crash if it's declared with the type any.

To Reproduce

Run this shell command:

vim -Nu <(cat <<'EOF'
    vim9script
    set rtp^=/tmp/some/
    mkdir('/tmp/some/autoload/', 'p')
    var lines =<< trim END
        vim9script
        fu script#legacy()
            eval s:Vim9({m -> 0})
            return x
        endfu
        def Vim9(y: any)
        enddef
    END
    writefile(lines, '/tmp/some/autoload/script.vim')
    au VimEnter * script#legacy()
EOF
)

Vim crashes.

Expected behavior

Vim doesn't crash.

Environment

• Vim version: 8.2 Included patches: 1-2567
• OS: Ubuntu 16.04.7 LTS
• Terminal: xterm(366)

Additional context

Regression introduced in 8.2.2212.

• backtrace
• valgrind log
• asan log

I think this is a simpler MWE:

vim9script
fu Foo()
    eval s:Bar({x -> 0})
endfu
def Bar(y: any)
enddef
Foo()

But with this one, I have to kill -9 Vim, which then doesn't dump a core. So no backtrace (and possibly no other logs either).

According to this post, there is no current way to disable insert delay after entering insert mode on a read-only file.

Since I'm almost always aware that I'm in read-only, and I'm using ":W" command! -bar -nargs=0 W silent! exec "write !sudo tee % >/dev/null" | silent! edit! when I want to save, there really is no need for any delay and only slows me down. The message is fine, the delay is not.

This is so that original Vi behavior can be kept (able to modify a buffer for a readonly file), while making sure that the user notices that there might be a problem. As mentioned, if you are intentionally changing a buffer, first reset the 'readonly' option to let Vim know that you know what you are doing. An option is just going to make things more complicated. Taking away the delay is going to make it much more likely the user doesn't notice the warning and continues changing the buffer, only finding out later that the file can't be written and all changes were a waste of time.

In ins_compl_bs() there is an explicit exception for omni completion. The comment suggests that this mode won't match everything. It does seem inconsistent to make an exception for these two completion modes. On the other hand, it appears to have been done intentionally and users may depend on the current behavior.

I think it's fine that getcharpos() returns the character index of the last character in the line. Returning a large number isn't helping. In case the script needs to know the position is actually "beyond end of the line" then getpos() can be used. Thus it's actually useful to have the two function return something different.

And that is with exactly the original reproduction steps? I can not reproduce it that way. If you actually do something else now, please say so.

Or maybe the issue is not at the script level, but in compiled code. Maybe this snippet should raise an error:

vim9script
def Func()
    var x: any
    x = ''
    eval x is 0
enddef
Func()

Not sure what the right choice is here. I think it would be convenient to be able to compare any types of operands with is and isnot. I have a few locations where I wrote something like this:

if typename(type) == 'string' && type == ''

If I had the guarantee that is will still be able to compare any types of operands in the future, be it at the script level or in compiled code, I would simplify these lines like this:

if type is ''

Some people agree, but not all. I wonder whether popular programming languages – with a type checking system – provide an extra set of comparison operators which don't raise an error when comparing operands with different types. That is, they first compare the types are identical, then the values.

I think javascript/typescript provide === which tests type equality and value equality, as well as !== which tests type inequality or value inequality. Maybe we should make is/isnot raise an error in compiled code, to be consistent with the script level; but also introduce the operators ===/!===?

Hi,

On Fri, Mar 5, 2021 at 6:46 AM lacygoill vim-dev-github@256bit.org wrote:

Interestingly enough, getpos() is affected but not getcharpos():

vim9script setline(1, 'some text') exe "norm! V\e" echom getpos("'>")

[0, 1, 2147483647, 0]

vim9script setline(1, 'some text') exe "norm! V\e" echom getcharpos("'>")

[0, 1, 9, 0]

Which seems inconsistent.

Yes. This needs to be fixed. The getcharpos() function should return the same value for column as getpos() in this case.

• Yegappan

Hi,

On Fri, Mar 5, 2021 at 4:55 AM lacygoill vim-dev-github@256bit.org wrote:

I understand that there is a technical reason behind this value:

That's intentional. Vim defines a MAXCOL value which is used to indicate the cursor is at the end of the line without specifically requiring knowing the line length ahead of time. This allows the behavior to stay the same even if the line length changes. Some of its uses are purely internal, but it does have external visibility in the case of commands like getpos().

Source: https://groups.google.com/g/vim_dev/c/oCUQzO3y8XE/m/opuczWwCtCsJ

But I still think that it looks unexpected for a plugin author. I wonder whether it would make sense to at least change the output of getpos():

If a plugin uses getcurpos() to save the current cursor position and then restores the cursor position using setpos(), then changing the return value of getcurpos() will break functionality.

Consider the following text in a buffer:

123 123456

If you position the cursor on '3' in the first line by using '$' then press j, then the cursor will be positioned on '6' in the second line. On the other hand, if you position the cursor on '3' in the first line by moving the cursor and then press j then the cursor will be positioned on '3' in the second line.

The 'curswant' value in the return list of getcurpos() is used for this functionality.

Regards, Yegappan

vim9scriptsetline(1, 'some text')exe "norm! V\e"echom getpos("'>")

[0, 1, 2147483647, 0]

Otherwise, we have to fix it like this:

vim9scriptsetline(1, 'some text')exe "norm! V\e"var pos: list<number> = getpos("'>") pos[2] = col([pos[1], '$'])echom pos

[0, 1, 10, 0]

As an example, this is what the vim-exchange plugin has to do here https://github.com/tommcdo/vim-exchange/blob/17f1a2cc0d009cfd7f0dcda06dd0f017fcc1c70b/plugin/exchange.vim#L292-L294 .

If it can't be changed because it would break the compatibility with existing legacy Vim scripts, maybe we could limit this change to Vim9 scripts?

Interestingly enough, getpos() is affected but not getcharpos():

vim9script
setline(1, 'some text')
exe "norm! V\e"
echom getpos("'>")

[0, 1, 2147483647, 0]

vim9script
setline(1, 'some text')
exe "norm! V\e"
echom getcharpos("'>")

[0, 1, 9, 0]

Which seems inconsistent.

What's the point of the delay in these lines?

https://github.com/vim/vim/blob/008bff967f7fcaa6af066f71d65bfbba5ef5c7d3/src/change.c#L54-L62

Is there a good reason for the delay?

I think it's working as intended, the problem is maybe that the behaviour is undocumented.

I understand that there is a technical reason behind this value:

That's intentional. Vim defines a MAXCOL value which is used to indicate the cursor is at the end of the line without specifically requiring knowing the line length ahead of time. This allows the behavior to stay the same even if the line length changes. Some of its uses are purely internal, but it does have external visibility in the case of commands like getpos().

Source: https://groups.google.com/g/vim_dev/c/oCUQzO3y8XE/m/opuczWwCtCsJ

But I still think that it looks unexpected for a plugin author. I wonder whether it would make sense to at least change the output of getpos():

vim9script
setline(1, 'some text')
exe "norm! V\e"
echom getpos("'>")

[0, 1, 2147483647, 0]

Otherwise, we have to fix it like this:

vim9script
setline(1, 'some text')
exe "norm! V\e"
var pos: list<number> = getpos("'>")
pos[2] = col([pos[1], '$'])
echom pos

[0, 1, 10, 0]

As an example, this is what the vim-exchange plugin has to do here.

If it can't be changed because it would break the compatibility with existing legacy Vim scripts, maybe we could limit this change to Vim9 scripts?

@dpelle I used a non-root user to test the vim as you said, but two test failures were still reported.

[weipan@centos8 vim]$ ./configure --with-features=huge --enable-gui=gtk3 --enable-python3interp=yes
[weipan@centos8 vim]$ make -j8
[weipan@centos8 vim]$ make test
-------------------------------
Executed:  3761 Tests
 Skipped:    71 Tests
  FAILED:     2 Tests


Failures:
        From test_matchfuzzy.vim:
        Found errors in Test_matchfuzzy():
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_matchfuzzy line 54: Expected 1 but got 4
        From test_messages.vim:
        Found errors in Test_quit_long_message():
        Run 1:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>58 line 1: Expected 'finished' but got 'running'
        Run 2:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>60 line 1: Expected 'finished' but got 'running'
        Run 3:
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[9]..VerifyScreenDump line 58: See dump file difference: call term_dumpdiff("testdir/failed/Test_quit_long_message.dump", "testdir/dumps/Test_quit_long_message.dump"); difference in line 1: "|^+0#0000e05#ffffff0|A| +0#0000000&@72"; difference in line 2: "|E+0#ffffff16#e000002|r@1|o|r| |d|e|t|e|c|t|e|d| |w|h|i|l|e| |p|r|o|c|e|s@1|i|n|g| |c|o|m@1|a|n|d| |l|i|n|e|.@1|s|c|r|i|p|t| |/|t|m|p|/|w|e|i|p|a|n|/|s|p|a|c|k|-|s|t|a|g"; difference in line 3: "|e|/|s|p|a|c|k|-|s|t|a|g|e|-|v|i|m|-|8|.|2|.|2|5|6|9|-|k|m|s|x|c|f|r|k|3|n|r|x|o|d|z|l|h|r|4|b|g|c|3|6|n|v|u|c|u|x@1|c|/|s|p|a|c|k|-|s|r|c|/|s|r|c|/|t"; difference in line 4: "|e|s|t|d|i|r|/|X|t|e|s|t|_|q|u|i|t|_|m|e|s@1|a|g|e|:| +0#0000000#ffffff0@48"; difference in line 5: "|l+0#af5f00255&|i|n|e| @3|1|:| +0#0000000&@64"; difference in line 6: "|-+0#00e0003&@1| |M|o|r|e| |-@1> +0#0000000&@64"
        command line..script /tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[502]..function RunTheTest[39]..Test_quit_long_message[12]..StopVimInTerminal[14]..WaitForAssert[2]..<SNR>6_WaitForCommon[11]..<lambda>62 line 1: Expected 'finished' but got 'running'
        Flaky test failed too often, giving up

TEST FAILURE
make[2]: *** [Makefile:49: report] Error 1
make[2]: Leaving directory '/tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir'
make[1]: *** [Makefile:2257: scripttests] Error 2
make[1]: Leaving directory '/tmp/weipan/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src'
make: *** [Makefile:39: test] Error 2

I wrote in my previous comment:

Hmmm, why do you run as root user? That's a bad idea. You should almost never need to login as root.

I should have added. If you want to build and install vim. You should instead be logged as a regular user and do something like this, where only the 'install' step needs privilege access (using sudo) to be able to install in /usr/local/...

$ cd vim
$ ./configure --with-features=huge --enable-gui=gtk3 --enable-python3interp=yes
$ make -j8
$ make test
$ sudo make install

@Tom-python0121 wrote:

[root@centos8 vim]# uname -a

Hmmm, why do you run as root user? That's a bad idea. You should almost never need to login as root. Running all vim tests as root seems very dangerous. It's a recipe for messing up your system.

Anyway, I tried to run that test as root on xubuntu-18.04 and it indeed fails:

First as regular user, the test passes when doing:

$ cd vim/src/testdir
$ make test_edit

Then same test as root:

$ sudo su
# make test_edit
Executed 64 tests                        in   9.340343 seconds
1 FAILED:
Found errors in Test_edit_file_no_read_perm():
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 8: Expected 1 but got 0
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 9: Expected [''] but got ['one', 'two']
command line..script /home/pel/sb/vim/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 10: Pattern '\\[Permission Denied\\]' does not match '\n"Xfile" \r\n"Xfile" 2L, 8B'
SKIPPED Test_edit_CTRL_V(): ebcdic feature missing
SKIPPED Test_edit_DROP(): dnd feature missing
Makefile:63: recipe for target 'test_edit' failed
make: *** [test_edit] Error 1

The test is:

func Test_edit_file_no_read_perm()
  CheckUnix
  call writefile(['one', 'two'], 'Xfile')
  call setfperm('Xfile', '-w-------')
  new
  redir => msg
  edit Xfile
  redir END
  call assert_equal(1, &readonly)
  call assert_equal([''], getline(1, '$'))
  call assert_match('\[Permission Denied\]', msg)
  close!
  call delete('Xfile')
endfunc

Indeed, when running as root, &readonly is 0. Of course, root can read a file with --w------- permissions. I suppose we should skip this test when running as root.

I did not dare running all other Vim tests as root as I don't want to accidentally mess up my system.

@brammool Yes, setting 'esckeys' does the trick - IIUC the fix will need some other check for p_ek somewhere.

@brammool It's a lot of that problem, and now it's the same problem with the latest version 8.2.2569:

[root@centos8 vim]# make test
……
-------------------------------
Executed:  3482 Tests
 Skipped:   302 Tests
  FAILED:     6 Tests


Failures:
        From test_edit.vim:
        Found errors in Test_edit_file_no_read_perm():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 8: Expected 1 but got 0
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 9: Expected [''] but got ['one', 'two']
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_edit_file_no_read_perm line 10: Pattern '\\[Permission Denied\\]' does not match '\n"Xfile" \r\n"Xfile" 2L, 8B'
        From test_excmd.vim:
        Found errors in Test_redir_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_redir_cmd line 20: command did not fail: redir! > Xfile
        From test_help.vim:
        Found errors in Test_helptag_cmd():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 20: command did not fail: r-xr--r--
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_helptag_cmd line 31: command did not fail: -w-------
        From test_matchfuzzy.vim:
        Found errors in Test_matchfuzzy():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_matchfuzzy line 54: Expected 1 but got 4
        From test_writefile.vim:
        Found errors in Test_write_readonly_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 9: command did not fail: write
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_write_readonly_dir line 14: Expected 'E509:' but got '"Xdir/Xfile1" E510: Can''t make backup file (add ! to override)': write
        From test_alot.vim:
        Found errors in Test_recover_root_dir():
        command line..script /tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir/runtest.vim[468]..function RunTheTest[39]..Test_recover_root_dir line 11: command did not fail: split Xtest

TEST FAILURE
make[2]: *** [Makefile:49: report] Error 1
make[2]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src/testdir'
make[1]: *** [Makefile:2257: scripttests] Error 2
make[1]: Leaving directory '/tmp/root/spack-stage/spack-stage-vim-8.2.2569-kmsxcfrk3nrxodzlhr4bgc36nvucuxxc/spack-src/src'
make: *** [Makefile:39: test] Error 2

And I'll show you the system I'm using：

[root@centos8 vim]# uname -a
Linux centos8 4.18.0-193.el8.aarch64 #1 SMP Fri May 8 11:05:12 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux
[root@centos8 vim]# cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 100.00
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid asimdrdm dcpop
CPU implementer : 0x48
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd01
CPU revision    : 0

I don't know if you say that all platforms can run successfully. However, the test result always tells me that the error is displayed and whether the source code is running properly. It tells us which line of error is reported.