Julia plugin host

[nhynes]

The syntax for plugins is similar to that used for Python except function is replaced by fn since the former is a reserved word.

Example plugin: https://gist.github.com/nhynes/41a30e4468f50a044a38

[bfredl]

I don't think the syntax in the example plugin really works, a macro if either @macro(a, b, c) (to the end of parens) or @macro a b c (to the end of line or enclosing expression) Inspired by the old new documentation syntax we could use

@autocmd BufEnter(pattern="*.jl", sync=false) ->
function autoload(vim, filename)
end

or maybe shorter form

@fn (sync=true, opt=val) ->
function DoStuff(args)
    do stuff
end

where -> can be ommited if function is on the same line, i e @fn (sync=true) EvalJulia(args) = eval(args[1]) Even if it breaks the julian convention of lowercase functions, I thinks its handy to just name the function/command with the name of the implementation function.

[bfredl]

Nice, I have some simplifications to the registration mechanism locally (only one pass over the plugin file), I will push tomorrow when I get it to work.

[bfredl]

I got so far to get simplified registration working. I will look into some more issues tomorrow as well as the macros.

[bfredl]

I also tried to implement the macro syntax. (same branch) I think it now cover all cases (one-line/multi-line functions, named/unnamed functions, 0/1/many options), but will do more testing tomorrow.

[bfredl]

FYI I am working a bit on testing (but not passing yet...)

There is also a question of management, now that this repo both is a Julia package and a Neovim plugin. I think the recommendation should be, to manage this repo using julia:s Pkg (as it tracks dependencies) , and add set rtp+=/path/to/.julia/Neovim to nvimrc

[nhynes]

FYI I am working a bit on testing (but not passing yet...)

I'm eager to see what you came up with. I had quite a bit of difficulty getting the macros to work as-is.

There is also a question of management, now that this repo both is a Julia package and a Neovim plugin.

Ah ha! I'm glad that you brought this up. I was wondering the same thing and, more generally, how this should be approached with other package+plugins. I also think that letting the language-specific package manager handle the package is the best option since it understand the semantics better. It would be great if the future Neovim plugin manager handled this situation automatically.

Just as an argument in favor of splitting the package and plugin, I foresee ambiguity in what it means to bump the version of the package/plugin. Perhaps this can be be simply resolved by changing the eventual plugin metadata file.

[bfredl]

some examples of macro syntax in my branch, see test.jl, not working on travis yet though (and needs more cleanup).

I think of adding shortcuts @fnsync for @fn (sync=true) etc as I suspect it is the most common option, and @fnsync function MyFunc(args) look better than @fn (sync=true) function MyFunc(args)

[nhynes]

I think that you might have run into the same difficulty that I had originally encountered. Consider the following plugin:

f() = "KABOOM"

@Neovim.fn (sync=true) ->
MacroNoFun(nvim) = f()

Running let v = MacroNoFun() results in the error: f not defined. If you macroexpand the macro in the above example, you'll likely find is that f is scoped in the macro's module and becomes Neovim.f. You could try putting the function back into the file, but that won't quite work either since the names will modified to prevent clashes. You might be able to solve this by getting f to refer to the plugin module, but I haven't found a way to do this.

[bfredl]

I think that could be solved with esc(). And now I remember, I have neovim/neovim#2961 locally which is needed for registration work, also on travis.

[bfredl]

I merged neovim/neovim#2961 upstream, as soon as the binary used by travis is updated (and testing is possible), I will get this ready for merge.

Now host+plugin initialization is very slow, 4-5 secs just for a test plugin, but as JuliaLang/julia#8745 seems to make progress, we could hopefully soon look into caching. Just caching Neovim.jl + API generated methods should be a good start, but we need to invalidate the cache when we detect that the API has changed (on nvim upgrade).

[bfredl]

Sorry for the delay, being a bit busy with other stuff. I finally got the host tests working on travis, as well as fixed the scoping issue. I will probably merge tomorrow-ish.

[bfredl]

I worked also a bit on documentation.

[bfredl]

I merged this for now. I'm sure there are more issues, but let's fix them as they pop up when developing plugins.