feat(api): nvim_exec2(), deprecate nvim_exec()

[echasnovski]

This is a follow up to this comment regarding implementation of nvim_exec() variant which takes opts table as second parameter. I managed to implement nvim_exec2() and make nvim_exec() use it internally. It is a result of searching across all codebase and git log and cherry-picking parts which seemed to belong here, so might be suboptimal. Seems to work and generally ready for review.

Right now nvim_exec2() needs explicit second {} argument. Its value output is false by default. Generally, all these are currently true:

• nvim_exec2('echo 1', {}) <=> nvim_exec('echo 1', false)
• nvim_exec2('echo 1', {output = false}) <=> nvim_exec('echo 1', false)
• nvim_exec2('echo 1', {output = true}) <=> nvim_exec('echo 1', true)
• nvim_exec2('echo 1', {output = 1}) => error
• nvim_exec2('echo 1') => error

Further details that I feel should be discussed with Core team before I proceed:

• Maybe there is a better name, than nvim_exec2()?
• Maybe requiring explicit {} can be dropped? I went with this approach because it seems to better align with other usages of opts. But maybe I am wrong here, because nvim_exec2('echo 1') does look nicer.
• Should nvim_exec() be deprecated? If yes, what should be done? I imagine something like:
  • Move its code to 'src/nvim/api/deprecated.c'.
  • Replace all its usage in both code and doc to nvim_exec2().
• Should I manually generate vimdoc in PR or is it automated somehow?

[clason]

Nice!

Maybe there is a better name, than nvim_exec2()?

Oh, if ever there was an invitation for bikeshedding...

nvim_execute? (Unfortunately, we went exactly the opposite route for nvim_execute_lua, which is deprecated in favor of nvim_exec_lua...) nvim_exec_viml then?

Both function will need to stay around for quite a while due to our strict API contract, anyway.

Maybe requiring explicit {} can be dropped? I went with this approach because it seems to better align with other usages of opts. But maybe I am wrong here, because nvim_exec2('echo 1') does look nicer.

No, an explicit {} is mandatory, I'm afraid. Remember that the API is exposed (in a consistent way!) across multiple entrypoints (Lua, vimscript, RPC), not all of which deal nicely with missing arguments.

(If this were possible, we wouldn't need to add a new function for it in the first place...)

Should nvim_exec() be deprecated? If yes, what should be done? I imagine something like:

As deprecated functions will not be removed before 2.0, there's quite a bit of time for that. I'd start with just adding @deprecated to the docstring and mentioning the replacement. (Again, see nvim_execute_lua for a model.)

[ii14]

I'm pretty sure @seandewar was also working on a new version of nvim_exec that supports executing vim script with specific SID.

In my opinion it should also return a dictionary, so in future you could also return a stack trace from vim script exceptions, because right now you only get the error message.

[justinmk]

Let's stick with nvim_exec2 as the name. It is a reminder to stop adding API functions that aren't extensible.

Should nvim_exec() be deprecated? If yes, what should be done? I imagine something like:

• Move its code to 'src/nvim/api/deprecated.c'.
• Replace all its usage in both code and doc to nvim_exec2().

Yes!

[justinmk]

can omit the doc except one @deprecated use nvim_exec2 line

[justinmk]

using TRY_WRAP may improve exception behavior. Don't need to make this optional.

see other functions in this file for TRY_WRAP example usage.

neovim/src/nvim/api/vimscript.c

Line 130 in f4518ef

TRY_WRAP({

[echasnovski]

@justinmk, didn't manage to find a way to do this. More thoughts in a recent comment.

[clason]

I'm pretty sure @seandewar was also working on a new version of nvim_exec that supports executing vim script with specific SID.

#16071, for the record

[echasnovski]

I'm pretty sure @seandewar was also working on a new version of nvim_exec that supports executing vim script with specific SID.

#16071, for the record

I was just about to ask it myself. @seandewar, is this PR reasonable before yours (or at all, even)? Looking at list of changes in first comment, I doubt it.

My ultimate goal with this is to eventually fix #18497. If this can be done within your PR, I am good with that. Also happy to help there (not sure of logistics and my understanding of complex changes, though).

[seandewar]

Working on this should be fine. My PR doesn't address #18497 anyway.

I did do a quick proof-of-concept for an nvim_exec2 that I briefly mentioned on Matrix a while back, but it relies on #16071 which is waiting for review. Because this takes opts, this can be easily extended after #16071 anyway, so no worries. 👍

For flexibility, I think it might be better to return a dict though.
For example, my concept of nvim_exec2 also returns the SID of the new script, which could then be optionally passed to nvim_exec2 to execute code in a different script context (no need to worry about implementing any of that SID stuff here, though).

[echasnovski]

Sorry for long delay. As often happens, I've got a plugin idea which wanted to focus on. I am now dedicated to finish this PR as my first OSS priority.

I rebased on latest master and force pushed changes:

• Deprecate nvim_exec() in source code.
• Update nvim_exec() test to be for nvim_exec2(). Also add one test for default options.
• Update other functional tests to use nvim_exec2() instead of nvim_exec() (ones which I managed to find). This basically replaces function name and true/false to { output = true/false }.

What I couldn't do:

• Figure out a way to use TRY_WRAP. And besides, current approach with HAS_KEY(opts->output) is more consistent with other more recent functions that use opts (like nvim_eval_statusline()). Maybe should keep it that way?
• Manage to update 'deprecated.txt'. I ran ./scripts/gen_vimdoc.py, but it only updated other places.

Is there anything else that should be done here? I suggest first merge this change and later try to add option resolving #18497.

[ii14]

Is there anything else that should be done here?

Returning a dictionary.

[echasnovski]

Returning a dictionary.

Oh, thanks, I forgot about this suggestion. I see how it can be useful. Will need more effort to make it happen, though :(

So, what is expected to be the output right now? Something like:

• If opts.output = false, then it is {}. Should it be the point of this PR to handle error traceback? So that the output is { traceback = { ... } } in case of an error (whatever ... is meant to be).
• If opts.output = true, then it is { output = ... }. The previous point about error traceback holds here too.

@justinmk, as you were the one who initially suggested nvim_exec2(), I'll wait for your feedback on this.

[ii14]

Yes, just an empty {} dict for output=false and {output='...'} when output=true. I think the current behavior of throwing an error is good to have by default, and tracebacks is something that should be opt-in. The point is just so it can be extended in the future, so it doesn't have to be necessarily implemented right now.

[justinmk]

What flag should control the "stop on error" behavior? What's a common name for this kind of thing? (from anywhere, not just vim...).

:help execute() has a "silent" and "silent!" arg but that seems wrong for nvim_exec2() because we don't really want "silence" we want "continue on error".

[echasnovski]

I like explicit names, so stop_on_error = true works for me.
Others off the top of my head: safe = true, try_catch = false.

[clason]

continue=false

[ii14]

continue is a keyword in some programming languages, could that be a problem?

[clason]

Not in Lua 5.1 :P

[gpanders]

What's a common name for this kind of thing? (from anywhere, not just vim...).

Shell / bash has set -o errexit for "stop on error".

[lewis6991]

Isn't the term used in vimscript abort which is used to annotate functions that should stop on error?

[echasnovski]

I've rebased previous work on current master. Will see if there are any CI issues and try to make nvim_exec2() return a value.

[echasnovski]

Yes, just an empty {} dict for output=false and {output='...'} when output=true. I think the current behavior of throwing an error is good to have by default, and tracebacks is something that should be opt-in. The point is just so it can be extended in the future, so it doesn't have to be necessarily implemented right now.

I ended up always returning table with string output field. For two reasons:

• It seems to be more consistent.
• Using empty Dictionary from C implementation of nvim_exec2() resulted into { [true] = 6 } when used from Lua. Didn't find a way to work around this on myself, plus did get a "it is a big mess" feedback from Bjorn. Not a huge problem having not empty dictionary as output, but doesn't provide the best user experience.

Edit: after a strong negative feedback, reverted this implementation to allow empty dictionary as output. Now output field in output is nil if opts.output = false.

Overview of changes in 'modify nvim_exec2() to always return table' commit:

• Move core implementation to helper function which is used as is in deprecated functions. Make nvim_exec2() be a wrapper around it.
• Modify deprecated functions to use helper.
• Update nvim_exec2() tests to use table inside eq().
• Update all tests to use nvim_exec2(..., { output = true }).output.
• Make sure that nvim_exec() is present only in "deprecated" parts of code base.

[echasnovski]

@justinmk, @ii14, @clason, I think this is ready for review.

Couple of notes:

• I used FUNC_API_DEPRECATED_SINCE(11) for nvim_exec() as FUNC_API_SINCE(11) for nvim_exec2() was suggested by make. Is this correct?
• CI failures don't seem to be related to this PR. Locally I have fails only for some log tests (but different ones from Ubuntu CI).

[zeertzjq]

==================== File /home/runner/work/neovim/neovim/build/log/ubsan.8002 ====================
= 
= =================================================================
= ==8002==ERROR: LeakSanitizer: detected memory leaks
= 
= Direct leak of 384 byte(s) in 1 object(s) allocated from:
=     #0 0x5643880211f6 in __interceptor_realloc (/home/runner/work/neovim/neovim/build/bin/nvim+0xcbf1f6) (BuildId: aa48ac05a3a133b3139a15efaca2cc19e0e5e212)
=     #1 0x564388e20406 in xrealloc /home/runner/work/neovim/neovim/src/nvim/memory.c:168:15
=     #2 0x5643882cf4bb in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #3 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #4 0x564388731b63 in api_wrapper /home/runner/work/neovim/neovim/src/nvim/eval/funcs.c:319:19
=     #5 0x5643886d73a9 in call_internal_func /home/runner/work/neovim/neovim/src/nvim/eval/funcs.c:242:3
=     #6 0x5643887e807e in call_func /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:1617:15
=     #7 0x5643887e5118 in get_func_tv /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:495:11
=     #8 0x56438881bd0e in ex_call /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:3072:9
=     #9 0x5643889096bb in execute_cmd0 /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:1620:7
=     #10 0x5643888e60cc in do_one_cmd /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:2279:7
=     #11 0x5643888d63d4 in do_cmdline /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:578:20
=     #12 0x5643893037c8 in source_using_linegetter /home/runner/work/neovim/neovim/src/nvim/runtime.c:1895:16
=     #13 0x564389303021 in do_source_str /home/runner/work/neovim/neovim/src/nvim/runtime.c:1946:10
=     #14 0x5643882d03ec in exec_impl /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:92:3
=     #15 0x5643882cf87a in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #16 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #17 0x564388ef3ed9 in request_event /home/runner/work/neovim/neovim/src/nvim/msgpack_rpc/channel.c:425:19
=     #18 0x56438956bc09 in state_handle_k_event /home/runner/work/neovim/neovim/src/nvim/state.c:117:7
=     #19 0x564388f88748 in nv_event /home/runner/work/neovim/neovim/src/nvim/normal.c:6611:3
=     #20 0x564388f4ca91 in normal_execute /home/runner/work/neovim/neovim/src/nvim/normal.c:1196:3
=     #21 0x56438956b9cd in state_enter /home/runner/work/neovim/neovim/src/nvim/state.c:99:26
=     #22 0x564388f2f914 in normal_enter /home/runner/work/neovim/neovim/src/nvim/normal.c:497:3
=     #23 0x56438805fbeb in main /home/runner/work/neovim/neovim/src/nvim/main.c:636:3
=     #24 0x7f60f2ac7d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
= 
= Direct leak of 384 byte(s) in 1 object(s) allocated from:
=     #0 0x5643880211f6 in __interceptor_realloc (/home/runner/work/neovim/neovim/build/bin/nvim+0xcbf1f6) (BuildId: aa48ac05a3a133b3139a15efaca2cc19e0e5e212)
=     #1 0x564388e20406 in xrealloc /home/runner/work/neovim/neovim/src/nvim/memory.c:168:15
=     #2 0x5643882cf4bb in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #3 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #4 0x564388ef3ed9 in request_event /home/runner/work/neovim/neovim/src/nvim/msgpack_rpc/channel.c:425:19
=     #5 0x56438956bc09 in state_handle_k_event /home/runner/work/neovim/neovim/src/nvim/state.c:117:7
=     #6 0x564388f88748 in nv_event /home/runner/work/neovim/neovim/src/nvim/normal.c:6611:3
=     #7 0x564388f4ca91 in normal_execute /home/runner/work/neovim/neovim/src/nvim/normal.c:1196:3
=     #8 0x56438956b9cd in state_enter /home/runner/work/neovim/neovim/src/nvim/state.c:99:26
=     #9 0x564388f2f914 in normal_enter /home/runner/work/neovim/neovim/src/nvim/normal.c:497:3
=     #10 0x56438805fbeb in main /home/runner/work/neovim/neovim/src/nvim/main.c:636:3
=     #11 0x7f60f2ac7d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
= 
= Indirect leak of 7 byte(s) in 1 object(s) allocated from:
=     #0 0x564388020dce in __interceptor_malloc (/home/runner/work/neovim/neovim/build/bin/nvim+0xcbedce) (BuildId: aa48ac05a3a133b3139a15efaca2cc19e0e5e212)
=     #1 0x564388e1ffc6 in try_malloc /home/runner/work/neovim/neovim/src/nvim/memory.c:88:15
=     #2 0x564388e201ac in xmalloc /home/runner/work/neovim/neovim/src/nvim/memory.c:122:15
=     #3 0x564388e2052a in xmallocz /home/runner/work/neovim/neovim/src/nvim/memory.c:194:15
=     #4 0x564388e2067b in xmemdupz /home/runner/work/neovim/neovim/src/nvim/memory.c:212:17
=     #5 0x564388260d53 in cstr_to_string /home/runner/work/neovim/neovim/src/nvim/api/private/helpers.c:369:13
=     #6 0x5643882cf713 in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #7 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #8 0x564388731b63 in api_wrapper /home/runner/work/neovim/neovim/src/nvim/eval/funcs.c:319:19
=     #9 0x5643886d73a9 in call_internal_func /home/runner/work/neovim/neovim/src/nvim/eval/funcs.c:242:3
=     #10 0x5643887e807e in call_func /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:1617:15
=     #11 0x5643887e5118 in get_func_tv /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:495:11
=     #12 0x56438881bd0e in ex_call /home/runner/work/neovim/neovim/src/nvim/eval/userfunc.c:3072:9
=     #13 0x5643889096bb in execute_cmd0 /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:1620:7
=     #14 0x5643888e60cc in do_one_cmd /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:2279:7
=     #15 0x5643888d63d4 in do_cmdline /home/runner/work/neovim/neovim/src/nvim/ex_docmd.c:578:20
=     #16 0x5643893037c8 in source_using_linegetter /home/runner/work/neovim/neovim/src/nvim/runtime.c:1895:16
=     #17 0x564389303021 in do_source_str /home/runner/work/neovim/neovim/src/nvim/runtime.c:1946:10
=     #18 0x5643882d03ec in exec_impl /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:92:3
=     #19 0x5643882cf87a in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #20 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #21 0x564388ef3ed9 in request_event /home/runner/work/neovim/neovim/src/nvim/msgpack_rpc/channel.c:425:19
=     #22 0x56438956bc09 in state_handle_k_event /home/runner/work/neovim/neovim/src/nvim/state.c:117:7
=     #23 0x564388f88748 in nv_event /home/runner/work/neovim/neovim/src/nvim/normal.c:6611:3
=     #24 0x564388f4ca91 in normal_execute /home/runner/work/neovim/neovim/src/nvim/normal.c:1196:3
=     #25 0x56438956b9cd in state_enter /home/runner/work/neovim/neovim/src/nvim/state.c:99:26
=     #26 0x564388f2f914 in normal_enter /home/runner/work/neovim/neovim/src/nvim/normal.c:497:3
=     #27 0x56438805fbeb in main /home/runner/work/neovim/neovim/src/nvim/main.c:636:3
=     #28 0x7f60f2ac7d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
= 
= Indirect leak of 7 byte(s) in 1 object(s) allocated from:
=     #0 0x564388020dce in __interceptor_malloc (/home/runner/work/neovim/neovim/build/bin/nvim+0xcbedce) (BuildId: aa48ac05a3a133b3139a15efaca2cc19e0e5e212)
=     #1 0x564388e1ffc6 in try_malloc /home/runner/work/neovim/neovim/src/nvim/memory.c:88:15
=     #2 0x564388e201ac in xmalloc /home/runner/work/neovim/neovim/src/nvim/memory.c:122:15
=     #3 0x564388e2052a in xmallocz /home/runner/work/neovim/neovim/src/nvim/memory.c:194:15
=     #4 0x564388e2067b in xmemdupz /home/runner/work/neovim/neovim/src/nvim/memory.c:212:17
=     #5 0x564388260d53 in cstr_to_string /home/runner/work/neovim/neovim/src/nvim/api/private/helpers.c:369:13
=     #6 0x5643882cf713 in nvim_exec2 /home/runner/work/neovim/neovim/src/nvim/api/vimscript.c:59:3
=     #7 0x56438823ee30 in handle_nvim_exec2 /home/runner/work/neovim/neovim/build/src/nvim/auto/api/private/dispatch_wrappers.generated.h:7394:19
=     #8 0x564388ef3ed9 in request_event /home/runner/work/neovim/neovim/src/nvim/msgpack_rpc/channel.c:425:19
=     #9 0x56438956bc09 in state_handle_k_event /home/runner/work/neovim/neovim/src/nvim/state.c:117:7
=     #10 0x564388f88748 in nv_event /home/runner/work/neovim/neovim/src/nvim/normal.c:6611:3
=     #11 0x564388f4ca91 in normal_execute /home/runner/work/neovim/neovim/src/nvim/normal.c:1196:3
=     #12 0x56438956b9cd in state_enter /home/runner/work/neovim/neovim/src/nvim/state.c:99:26
=     #13 0x564388f2f914 in normal_enter /home/runner/work/neovim/neovim/src/nvim/normal.c:497:3
=     #14 0x56438805fbeb in main /home/runner/work/neovim/neovim/src/nvim/main.c:636:3
=     #15 0x7f60f2ac7d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 69389d485a9793dbe873f0ea2c93e02efaa9aa3d)
= 
= SUMMARY: AddressSanitizer: 782 byte(s) leaked in 4 allocation(s).
===================================================================================================

[echasnovski]

Thanks, @zeertzjq!

These all seem to be related to this PUT() call but I have no idea what can be wrong with this. This is mostly a modified copy-paste from some other part of code base.

[ii14]

• Using empty Dictionary from C implementation of nvim_exec2() resulted into { [true] = 6 } when used from Lua. Didn't find a way to work around this on myself, plus did get a "it is a big mess" feedback from Bjorn. Not a huge problem having not empty dictionary as output, but doesn't provide the best user experience.

I believe { [true] = 6 } is correct for empty dictionaries, that's (unfortunately) how API types are deserialized for Lua. See :h lua-special-tbl

[echasnovski]

I believe { [true] = 6 } is correct for empty dictionaries, that's (unfortunately) how API types are deserialized for Lua. See :h lua-special-tbl

Well, I don't dispute that (but having at least some clue of why it's happening is better, of course). My reasoning is more about that this is not empty Lua table, which I find rather inconvenient to both document and (especially) use. So I think having output field be always string is a somewhat fitting solution here.

[echasnovski]

@echasnovski #22737 got merged -- can you rebase? What's left to do after that?

Rebased. Now output is vim.empty_dict() instead of previously { [true] = 6 } and it seems to be expected.

I don't see anything to be done in order to replace nvim_exec() with nvim_exec2(). After this PR is merged, it would be good to extend nvim_exec2() to fix #18497. It seems to be a good idea to do that in a separate PR, as this one is already quite crowded.

[bfredl]

use api_object_to_boolean()

[bfredl]

same here

[bfredl]

otherwise lgtm

[clason]

@echasnovski do you want to squash these down? or I can squash to a single commit when merging.

[echasnovski]

@echasnovski do you want to squash these down? or I can squash to a single commit when merging.

I kept doing it in separate commits for easier reviewing. I don't mind you (or anyone else) squash merging this. Or I can do this myself once everyone is happy and it is time to merge.

[clason]

Depends on whether you want to keep it as (fewer) separate commits; then you have to do it.

But it's always nicer if the contributor squashes and writes a nice commit message (you know, with "Problem:... Solution:...") for the squashed commit.

[echasnovski]

@justinmk, LGTY?

[justinmk]

Should output param be a string, is it likely that a caller would want to also capture "error" output in the future? So the current accepted values would be output: "yes"|"none" and in the future it might be output: "yes"|"none"|"all" ? Or could be an Integer.

If this is not expected then it can stay boolean.

[echasnovski]

I am not sure here. To me having a one-to-one relation between opts and returned dictionary seems like a better design right now. So if opts.output = true, then output in result will represent output. If opts.error = true, then errors will be safely captured and result error will have those possible error captures. And so on.

[justinmk]

Why not call nvim_exec2, why do we need exec_impl ?

[echasnovski]

Short answer: I tried but couldn't do it. This worked, so decided to use it.

Long answer: I didn't manage to write proper C code to get output field from nvim_exec2() dictionary output.

Code for nvim_exec() was like this:

String nvim_exec(uint64_t channel_id, String src, Boolean output, Error *err)
  FUNC_API_SINCE(7)
  FUNC_API_DEPRECATED_SINCE(11)
{
  Dict(exec_opts) opts = { 0 };
  opts.output = BOOLEAN_OBJ(output);
  Dictionary exec2_output = nvim_exec2(channel_id, src, &opts, err);

  for (size_t i = 0; i < exec2_output.size; i++) {
    if (strequal(exec2_output.items[i].key.data, "output")) {
      return exec2_output.items[i].value.data.string;
    }
  }
  return (String)STRING_INIT;
}

I thought this should essentially be return nvim_exec2(src, { output = output }).output but it always returned empty string (while same nvim_exec2() call does return non-empty string). There seems to also be some potential memory leak, so Bjorn suggested to write a helper while leaving nvim_exec2() to construct output dictionary.

[justinmk]

If you plan to do the followup soon, we can merge this and address the comments above in the next PR.

[echasnovski]

If you plan to do the followup soon, we can merge this and address the comments above in the next PR.

Well, define "soon" :) I do want to not drag this out and find a way to make completely simulate :source ... with Lua API. But don't feel comfortable with time estimations right now. Seems like starting working on it within next month, maybe? Definitely not right now rushing and blocking 0.9.0 release.

[echasnovski]

Updated outdated comment and added deprecate `nvim_exec()` in commit message.