> Maybe it is because of the fact that my daily job requires me to do manual
> compilation frequently but I don't find this very difficult.
Yeah, I use a package manager and only compile manually when I absolutely 
to because I don't like dealing with dependencies. A matter of perspective I

> In fact, opex works well with neovim as well for languages with providers
> (e.g. lua, python, ruby, shell and vim). I don't know much about remote
> plugins in neovim but I feel like they have a distinction between 
> and remote plugins, because I can't seem to find some of the interfaces in
> vim (perl, tcl and mzscheme).
Right, providers and remote plugins are two different things. The idea 
providers is that some functionality should not be implemented in Neovim, 
instead there should be a place to hook an application into. Take for 
the `:make` command: make is not built into Vim, instead you can set the
`makeprg` variable to a binary of you choice. Providers take this idea 
offloading for example the clipboard support to an external program.

Remote plugins on the other hand are plugins written in a foreign language.
Where it might get confusing is that sometimes there is both: you can write 
plugin in Python as a remote plugin (new style) or you can write it in the 
style. When writing it the old style there needs to be a provider to supply 
Python implementation for the `:python` command to work (since there is none
built into Neovim itself).

There is no provider for the old `:mzscheme` command yet. I am planning to 
around to it, but it has very low priority. If anyone wants to help out I'm
open to that.

> If a remote plugin can provide such an interface with a similar command, 
> I think opex can simply be configured with something like the following:
>    autocmd Filetype scheme let b:opex_cmd = 'RacketEval'

Right, that's the idea. Keep in mind that there is no difference between
functions defined in VimScript and those defined in remote plugins, so you
could also create a function reference like `funciton('RacketEval')`.

> I think the biggest problem is that the community more often talks about 
> possibilities rather than showing existing work. End users may simply 
> something that exists and simply works.
Many projects start with the idea of rewriting Vim, so you get someone who 
"I'm going to rewrite Vim in Python, and it will be much better code". Then 
starts implementing features one by one, and eventually he reaches the point
where he himself is satisfied with the result because it fits his own 
needs. He
never gets around implementing the rest and so you end up with a clone that
isn't compatible with anything from the Vim ecosystem. Neovim is a fork, so 
starts with full Vim compatibility and the developers can surgically remove 
replace the bits that need to be changed.

> In fact, I was already aware of neovim.rkt and I'm very glad you're here 
> give some feedback. It would be nice if you can give some information 
> the current situation in neovim and neovim.rkt.
Neovim.rkt is something I do on the side and it was my first time doing
something with asynchronicity and message passing, so progress is slow. It 
work though, but don't expect graceful error handling. I also haven't yet
committed to the public interface, but what I have now looks promising in my

As for Neovim, that project is doing great. I have completely replaced Vim 
there are already plugins making use of its new features. Externalising
language support also makes it easier to maintain when you can just swap out
components. My personal killer feature is the terminal emulator. I thing the
fact that Vim has been copying features from Neovim instead of the other way
around should be telling enough.

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to