What's the difference between call and execute?

Question

E.g., in this snippet

    if words[0] == "\"spellgood:"
      call remove(words, 0)
      for word in words
        execute "silent spellgood! " . word
      endfor
    endif

taken from "The first and last 5 lines of a file? Use for file specific spell ignore list?"

Answer 1

As described in :help call, call is for invoking a built-in or user-defined function. It's useful to use call if you're invoking a function without the intention of capturing the return value, because of how vim's scripting works. That is, if you have a function foo that returns an integer, you must:

call foo()

to call foo without caring about the result, whereas:

let result = foo()

can be used to call foo and put the result in result. Note how call is not required for the second example. call also can take a range, which has the effect of invoking the function for every line in that range, usually.

:help execute, on the other hands, reveals that execute is for evaluating strings as Ex commands. Normally you don't need to use execute in vim scripts, as most of what you type in them is interpreted as an Ex command. However, execute exists and is particularly useful for invoking commands built up at runtime, as was done in the answer you linked to in order to add a word discovered at runtime to the spelling dictionary.

Answer 2

• We use a command just by writing it
• When we use a string as a command, put execute before the string

These 2 lines get the same output

:echo 'hi_1'

:execute "echo 'hi_1'"

NOTE
: indicates a ex command, instead of an option, motion or other things in vim (try :help :bar vs :help bar )

---

(Thank @filbranden for reminding me of my mistakes. And since answers above have pointed out differences between :execute vs :call, below I add something I think useful, without repeating my revise of answers above)

:execute

in vim's help

:exe[cute] {expr1} ..

Executes the string that results from the evaluation  of {expr1} as an Ex command.

When I need to give multiple commands in one line, I usually use | (see :help :bar, not :help bar). When that line is complicated, I need to use :excute as a work around of |

Example of using | :

: echo 'hi_1' | echo 'hi_2'

A real example of using | and execute:

autocmd BufReadPost *
     \ if line("'\"") > 0 && line("'\"") <= line("$") |
     \   execute "normal g`\"zv" |
     \ endif

About :normal

:norm[al][!] {commands}                 *:norm* *:normal*
            Execute Normal mode commands {commands}.  This makes
            it possible to execute Normal mode commands typed on
            the command-line.  {commands} are executed like they
            are typed.
            This command cannot be followed by another command,
            since any '|' is considered part of the command.

            An alternative is to use |:execute|, which uses an
            expression as argument.  This allows the use of
            printable characters to represent special characters.

Example of representing special characters:

:exe "normal \<c-r>" (redo)

:normal and bar

:normal command see the '|' as a argument, and can therefore not be followed by another Vim command

:normal gg | echo 'hi' can't get anything printed. It meas: under normal mode, types gg | echo 'hi', where | is a motion

:help | (:help bar)

To screen column [count] in the current line. |exclusive| motion. Ceci n'est pas une pipe.

"Ceci n'est pas une pipe", French for "This is not a pipe" . (One interpretation is that the pipe in the painting is not a pipe, but rather a drawing of a pipe.)

A real example of :execute (with :normal)

func Print_n()
    if &filetype == 'python'
        execute "normal yiwoprint(f'{= }')"
        execute "normal hhhhhp"
    elseif &filetype == 'cpp'
        " execute 'normal yiwocout<<""<<' | execute 'normal hhhpf<lpa<<endl;'
        execute 'normal yiwocout<<""<<'
        execute 'normal hhhpf<lpa<<endl;'
    elseif &filetype == 'zsh'
        execute 'normal yiwoecho ${}'
        execute "normal hp"
    elseif &filetype == 'vim'
        execute 'normal yiwoecho &'
        execute "normal p"
    endif
endfunc

func Print_v()
    if &filetype == 'python'
        # execute "visual y"
        execute "normal oprint(f'{= }')"
        execute "normal k$hp"
    endif
endfunc

nnoremap _p :call Print_n()<CR>
vnoremap _p :call Print_v()<CR>

Answer 3

Petrie's answer is only partially true.

By partially I mean, take for example, bdelete. Supposedly, as stated by vim's manual, it states that by providing a number N identifying a buffer (as in using the number provided by ls or ls!), you can delete a buffer in vimscript. Well that is only true, if you provide a literal number, like bdelete 6, you will delete buffer 6. However, if you pass a variable to bdelete that contains the buffer number to delete like, bdelete g:buffer_to_delete (where g:buffer_to_delete=6), it will not work! In fact in vimscript you can not write :bdelete g:buffer_to_delete or call bdelete g:buffer_t_delete. However, you can treat the command as a string and execute it like so, exec "bdelete".g:buff_to_delete, that will work!

Thus vimscript call DOES NOT invoke user-defined or internal functions all the time. There are situations where exec must be used because call doesn't function as it is supposed to. This situation has been around for many years and still lingers today with vim 8.0. So be aware and follow the rule:

If you can't make the call try executing instead.

It is not clear when you can use call and when you must use exec for I have found the above situation occurring erratically. So start with call then if it fails, exec will work, as of yet I haven't found an instance when it doesn't, fortunately!

Note to Vimscript World: there are other nuances like the above that should be spelled out clearly in the vim documentation, or at least fixed in the vim code! I and many others I know have spent many many hours in years passed wasting time figuring out these nuances. I thought Emacs was truly terrible in this regard, but Vim too has its own undisclosed idiosyncrasies.

And before you say it....yes I have provided these issues years ago. I am only writing this now, because I feel a lot of sympathy for Yossi for going through this problem, because I had the same problem many years ago.

Yossi: keep an open mind with Vimscript it lacks quite a bit of common-sense, but if you keep your wits about yourself you can get much for your time spent on vim, than you would with say with Emacs! Trust me, I've been using Emacs and (G)Vi(m) for 30 years now. (G)Vi(m) is the way to go...Emacs is fast dying, and rightly so :-( {Hey Stallman, don't you think its time to admit Emacs sux? Why go to all the trouble and create Evil, when Vim is free?}

Keep pushing Yossi! It will pay off! (Yes everybody, I know this reply is a year late, but I can bet you there are many other Yossi's out there)

Let's hope, Vim 9.0, will do a better job than Vim 8.0. (I hope I will be still alive to see 9.0!)