I agree manual compilation can be quite a hassle. I have tried to avoid such configurations for many years myself. Then I decided I could just do it once for all supported languages in vim and be done with it. For racket, if you have it installed you most likely just need something along the line:
./configure --enable-mzschemeinterp && make && sudo make install 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. Having the correct packages installed is the difficult part but if you're working on racket then it is likely already installed on your machine. I would say racket is only obscure to those that are not using it. If I were to develop a vim plugin using mzscheme interface but has nothing to do with racket language itself then it would really be a problem. I'm aware of neovim project. 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 providers and remote plugins, because I can't seem to find some of the interfaces in vim (perl, tcl and mzscheme). Or they may have simply removed these in the account that nobody is using them. If a remote plugin can provide such an interface with a similar command, then I think opex can simply be configured with something like the following: autocmd Filetype scheme let b:opex_cmd = 'RacketEval' Neovim indeed suggests good engineering solutions to some of the problems in vim. I think the biggest problem is that the community more often talks about the possibilities rather than showing existing work. End users may simply prefer something that exists and simply works. In fact, I was already aware of neovim.rkt and I'm very glad you're here to give some feedback. It would be nice if you can give some information about the current situation in neovim and neovim.rkt. Regarding opex, it is a tiny plugin that consists of a few hundreds lines of codes. It is an iteration of a very simple idea that uses the existing work . It is finished and I doubt I will change anything except for maybe small bug fixes. It already works well for myself and I frequently use it to prepare lecture notes or do simple literate programming. This is all that matters for me. I put the source to public and announced it in a few places so that maybe a few other people on the planet may find it useful as well. Gokcehan On Wednesday, December 20, 2017 at 1:49:29 PM UTC+3, HiPhish wrote: > > Having to re-compile Vim with support for a language is one of its bigger > drawbacks. It's fine for a common language like Python, but the more > obscure it > gets, the less likely it is that your plugin will be of any use to other > people. You should take a look at Neovim: > https://neovim.io/ > > Neovim is a fork of Vim which aims to bring the code up to modern > standards. It > is not a rewrite, so all existing plugins should work and the Neovim > developers > keep up with new Vim patches. > > One of the innovations in Neovim is its remote API. In Vim you have to > compile > Vim with support for a foreign language, but in Neovim that support can be > retrofitted to the editor as an external process. So for example, if you > want > to write Neovim plugins in Python you install the Python client via pip. > And if > you want to write plugins in Racket you install my Racket client: > https://gitlab.com/HiPhish/neovim.rkt > > You could then write an "evaluator" plugin in Racket like this: > > #lang racket > ;; Save in a file like '~/.config/nvim/rplugin/racket/eval.rkt' > (require nvim) > (nvim-function "RacketEval" > (λ (args) > (define str (vector-ref args 0)) > (call-with-input-string str (λ (in) (eval (read in)))))) > > This won't actually work with an argument like "(+ 2 3)", Racket complains > that > the '+ is an undefined identifier, but that's a problem on the Racket side > (I > don't know that much about Racket yet to be able to do eval magic), not on > the > editor side. The RacketEval function is like any other Neovim function, > except > that it offloads the work to an external process behind the scene, but the > user > never notices that. > > The Racket client is still under development, I have not yet committed > fully to > the public interface and I need to take care of some edge cases when > something > goes wrong. Other than that, the client fully works. > > > On Sunday, December 17, 2017 at 2:33:26 PM UTC+1, gokceh...@gmail.com > wrote: >> >> ... >> > -- 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.
