(mini.test) Add child.lua_func() method

[stasjok]

I like mini.test, but I don't particularly like to write lua code as strings, because it looses syntax highlighting/code completion/type checking etc. I started to use this little function and I think it works pretty well. I thought that I can contribute it here.

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md

[echasnovski]

That is interesting! Thanks for the PR!

If I understand correctly, the usual use case is to define function in current process (mostly to get syntax highlighting), copy it to child, execute, and return value? Are there any other use cases I am missing here?

[stasjok]

That is interesting! Thanks for the PR!

If I understand correctly, the usual use case is to define function in current process (mostly to get syntax highlighting), copy it to child, execute, and return value? Are there any other use cases I am missing here?

I don't think so. It's basically the same as child.lua(), but you specify a lua code wrapped in a function. So it's easier to write and spot any errors, because it's a real lua code, not a string.

Also I removed backticks from child type in MiniTest.new_child_neovim annotations, because it allows lua-language-server to provide completions for child variable (when I use it). But it breaks highlighting in doc file. I can change it back if it's not wanted. Maybe something can be done in mini.doc so that it works both in doc generations and lua-language-server?

[stasjok]

Other plus for a function it that you can use arguments anywhere. With child.lua() you're forced to use all arguments as ... as a group.

[echasnovski]

I don't think so. It's basically the same as child.lua(), but you specify a lua code wrapped in a function. So it's easier to write and spot any errors, because it's a real lua code, not a string.

My main issue with this is that during test writing author can write function outside of string and only move it there before execution. Although iterating on writing that function is certainly easier with this PR's function. So it is good to have, but not strictly necessary, which is more of a "helpers" territory than 'mini.test' itself.

I'll think about it.

Other plus for a function it that you can use arguments anywhere. With child.lua() you're forced to use all arguments as ... as a group.

Not really sure I understand this.

Also I removed backticks from child type in MiniTest.new_child_neovim annotations, because it allows lua-language-server to provide completions for child variable (when I use it). But it breaks highlighting in doc file. I can change it back if it's not wanted. Maybe something can be done in mini.doc so that it works both in doc generations and lua-language-server?

Not really sure about this either. My main concern with annotations right now is about help generation. If EmmyLua doesn't support surrounding for returned object name, than I'd probably keep those backticks.

[stasjok]

Not really sure about this either. My main concern with annotations right now is about help generation. If EmmyLua doesn't support surrounding for returned object name, than I'd probably keep those backticks.

OK, I'll remove it, because it's not relevant to current feature. Annotation of @return can be: <type>, <type> <var_name> <comment>, <type> #<comment>. So in @return first word always should be the type and I think mini.doc should wrap it. Now looks like it's wrapping only internal lua types.

Other plus for a function it that you can use arguments anywhere. With child.lua() you're forced to use all arguments as ... as a group.

Not really sure I understand this.

It's not really important, but was I meant was, e.g.:

child.lua_func(function(a, b)
  func1(a)
  func2(b)
end, 1, 2)

Here I can use arguments a and b in different places. With child.lua('<some code>', {1,2}), in lua chunk I have .... I need to local a = ...; local b = select(2, ...) first to get arguments separately. I guess it's a rare case.

[echasnovski]

It's not really important, but was I meant was, e.g.:

child.lua_func(function(a, b)
  func1(a)
  func2(b)
end, 1, 2)

Yeah, that's nice to have.

I'll take some time thinking about it. Probably at least until the next release of 'mini.nvim' which is planned some time in end of August (usually prefer adding new features at the start of new development cycle).

[echasnovski]

Thanks again for the contribution! Sorry for taking so long to react, was trying to finish things with 'mini.pick' as quickly as possible.

I've merged this in a separate branch to make a few finishing touches and then back to main.

Edit: This should be a part of main branch.