Vim: extend automatic line continuation to autocmds and custom Ex commands

[lacygoill]

Is your feature request about something that is currently impossible or hard to do? Please describe the problem.

It is cumbersome to split a long autocmd or custom Ex command on multiple lines to improve its readability, because we need to add a leading backslash on each splitted line.

And it is cumbersome to join a long autocmd or custom Ex command on a single line when it gets shorter after a refactoring, because we need to remove a leading backslash on each joined line.

Describe the solution you'd like

In Vim9 script, extend the concept of automatic line continuation to autocmds and custom Ex commands.

Describe alternatives you've considered

I guess I could try a plugin such as splitjoin, but it would introduce one more dependency; and the backslashes would still make the code a little less readable.

Additional context

Vim already allows us to omit the leading backslash when a line starts with ->, even at the script level (i.e. no need of a :def function):

vim9script
let result = [3, 2, 1]
           ->reverse()
           ->join()
echo result

If Vim can allow an automatic line continuation in a multiline assignment, maybe it could do the same in a multiline autocmd. Instead of looking for -> at the start of a line, maybe it could look for |. As far as I can tell, a bar at the start of a line has no useful meaning. Its only effect is to print the current line (is it documented?):

:|

Which you can already get with the much more readable :print command.

We can already refactor this autocmd in Vim script legacy:

autocmd CursorHold * call A()
                  \| call B()
                  \| call C()

into this in Vim9 script:

autocmd CursorHold * A()
                  \| B()
                  \| C()

With the enhancement, we could go a little further:

autocmd CursorHold * A()
                   | B()
                   | C()

Similarly, this custom Ex command in Vim script legacy:

com MyCmd call A()
       \| call B()
       \| call C()

Can be refactored into this in Vim9 script:

com MyCmd A()
       \| B()
       \| C()

With the enhancement, we could write:

com MyCmd A()
        | B()
        | C()

---

I was thinking about multiline mappings too, but it seems it wouldn't be possible.

Contrary to autocmds and commands which run in the context of the script where they're defined, and thus can leverage the new Vim9 syntax, mappings run outside the script; therefore, they can't leverage the new Vim9 syntax.

[brammool]

We haven't yet discussed how to specify whether the argument of :autocmd and :command uses legacy Vim script syntax or Vim9 script syntax. Let's do that elsewhere.
So this is about the proposal to make a leading bar after an :autocmd and :command line a continuation line. As you mention, the main advantage is that lines can be joined and split without further edits, so long as the split is just before the bar.
I think that can work. It fits in with the Vim9 script work, in the sense that we take away a valid, but hardly ever used, old Vi command. Thus it's not backwards compatible.

[lacygoill]

It would also be useful for global commands.

Right now, we need explicit line continuations:

g/pat/ cmd1
   \ | cmd2
   \ | cmd3
   ^

It would be simpler to edit this type of commands without line continuations:

g/pat/ cmd1
     | cmd2
     | cmd3

[lacygoill]

Thank you for implementing this. I think it will be really appreciated; explicit continuation lines are one of the main reasons why people dislike Vim script. The more we can omit them, the better.

Some feedback: I've quickly tested the feature, and while it works in a :def function:

vim9script
def Func()
    au CursorHold * echom 'first'
        | echom 'second'
    do CursorHold
enddef
Func()

first
second

It doesn't work at the script level:

vim9script
au CursorHold * echom 'first'
    | echom 'second'
do CursorHold

E749: empty buffer
first

Obviously, it is much more important that it works in a function than at the script level. Still, it's inconsistent. If it's working as intended or can only work in a function, then maybe we should document this limitation.