Autocommands sometimes not parsed correctly anymore, since 8.2.1365

[bfrg]

Describe the bug
Since bb1b5e2 (8.2.1365) autocommands are not always parsed correctly anymore.

To Reproduce

1. Run vim --clean test.vim -S test.vim with

   augroup test
       autocmd!
       autocmd BufReadPost *
               \ if !exists("g:leave_my_cursor_position_alone") |
               \     if line("'\"") > 0 && line ("'\"") <= line("$") |
               \         exe "normal! g'\"" |
               \     endif |
               \ endif
   augroup END

2. Run :edit foo | buffer #. Alternatively put the cursor on a keyword and press K.
3. Result:

   Error detected while processing BufRead Autocommands for "*":
   E121: Undefined variable: line
   

Expected behavior
No errors.

Environment
Vim version 8.2.1377

[lacygoill]

Simpler example:

vim -Nu NONE +"echo line ('.')"

---

In the original example, the regression is triggered by an extra space on line 5:

\     if line("'\"") > 0 && line ("'\"") <= line("$") |
                                ^
                                ✘

[bfrg]

Thank you. I didn't notice the space. The snippet is from /etc/vim/vimrc provided by my distro.

[chrisbra]

I would say, it's a good thing that it errors on the extra space.

[jottkaerr]

I would beg to differ. IMHO white space inside a line is a purely aesthetic decision and should never be enforced by syntax rules. For example, I find something like

let s = 'initial value'
let s = do_something     (s, 'text',      1)
let s = do_something_else(s, 'more text', 2)

much more readable than

let s = 'initial value'
let s = do_something(s, 'text', 1)
let s = do_something_else(s, 'more text', 2)

I have been bitten by this regression today, also. And in my case it was triggered by multiple plugins from other authors that used spaces before and after parentheses.

[WolfgangMehner]

I have been bitten by this regression today, also. And in my case it was triggered by multiple plugins from other authors that used spaces before and after parentheses.

This causes huge problems for me as well. I agree with @jottkaerr, you should not conflate the syntax and linting, because linting is optional, the syntax of the language obviously is not.

[chrisbra]

i think it is fixed by bbd3e3c

[bfrg]

Thank you. Looks like it works again. Therefore closing.

[jottkaerr]

Yes, spaces around parentheses seem to work now, but there is still a problem with spaces around braces

Error detected while processing C:\Users\JKR\.vim\plugin\perl-support.vim
[238]..function <SNR>63_GetGlobalSetting:
line    4:
E720: Missing colon in Dictionary: }

The relevant line is

		let { 's:'.lname } = { 'g:'.gname }

[WolfgangMehner]

To be precise, the problem is with "curly braces names", not dictionaries. The error message is slightly off here.

[brammool]

Jürgen Krämer wrote:

I would beg to differ. IMHO white space *inside* a line is a purely aesthetic decision and should never be enforced by syntax rules. For example, I find something like ``` let s = 'initial value' let s = do_something (s, 'text', 1) let s = do_something_else(s, 'more text', 2) ``` much more readable than ``` let s = 'initial value' let s = do_something(s, 'text', 1) let s = do_something_else(s, 'more text', 2) ``` I have been bitten by this regression today, also. And in my case it was triggered by multiple plugins from other authors that used spaces before and after parentheses.

It's not purely aesthetic. We have the :echo and :execute commands that take multiple arguments, e.g.: :echo Func 'string' Normally, putting an expression in parens does not change its meaning, but here it does: :echo Func ('string') Now is Func a function reference or a variable containing a string? That actually matters for how this is interpreted. For Vim9 I'm going to make white space usage more strict. Not only for the above problem, but in general to avoid people writing ugly code. In Vim9 script the above is clearly two separate arguments. If you want a function call, you need to remove the spaces: :echo Func('string') And now we can check that Func is a function and give an error if it's not. This avoids mistakes that are hard to spot. Also to avoid that I have to fix tests that contain: let sdf=asdf Which should be: let sdf = asdf to make it easy to read. So it's also going to save me time, because the first will just fail. Anyway, existing scripts should not fail because of these changes, but it's not properly covered by tests, thus you need to complain if something breaks. I see a remaining problem was already reported.

…

-- In a world without fences, who needs Gates and Windows? /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///