Anyone interested to bring vim-hy up-to-date?

[pyx]

I just saw this https://github.com/hylang/vim-hy/issues/17, but I decided to open the issue here for the sake of visibility.

Am I the only one using vim to write Hy?

My stack, for anyone interested:

• vim-hy for syntax(does lisp actually have that?!? :smile:) highlighting, indentation, does not work now :disappointed:
• vim-slime to send code to Hy REPL inside screen/tmux session
• paredit (structural-edit (s-expression (in (vim)))) also part of slimv, which I use occasionally.

[vodik]

Hmmm, what if we did a hy-language-server?

[gilch]

@vodik can you elaborate more on that?

Also, @hylang/core, any takers for maintaining vim-hy? If not, I guess the next candidates would be people who cared enough to make a recent PR to vim-hy.

[vodik]

The language server protocol is a spec that came from Microsoft and was I think first implemented in vscode, but it has caught on in the general editor community, with there being good vim, neovim, and emacs support. Emacs, in fact, will likely ship with support out of the box soon (rms himself advocating for it).

The idea is you spin up a companion process that receives information about changes in the file. It, then, takes on ide functionality on your behalf across a standard protocol, covering style checking, code completion, code navigation (e.g. jump to definition), and auto formatting.

This, in turn, reduces the need to maintain otherwise duplicates functionality in hy-mode/vim-hy, and would help us give a good out of the box support to other editors with language server support.

I've personally switched from using anaconda-mode to lsp-mode with the python-language-server and I think its a major improvement.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[pyx]

Hmmm, what if we did a hy-language-server?

@vodik that's a good idea, except that the syntax of Hy is constantly changing now (a norm before 1.0), that will need someone close enough to the core team involve. I can help if I have the understanding of Hy's code base (which I didn't find time to do so). Maybe that's a good excuse to start reading the source.

BTW, Since I opened this issue, I read a bit of vim-hy's source, I found:

1. due to the design of vim script, the language, it's hard to read.
2. the indentation support is writing in hy, which sounds great, but in fact, this makes hy a hard requirement, and this does not work with virtual environments. This is a showstopper.
3. many part of the code could use automation (eg. code generation).

Thus, I am planning a rewrite...

[gilch]

@vodik interesting. So we could get even more editors than vim and emacs working with Hy without too much extra effort. Good tooling is important for the community. @ekaschalk what do you think of this? Have you used one of these servers with emacs before?

[vodik]

Yeah, I'd volunteer working on it once I get my backlog dealt with.

[ekaschalk]

Yea there are a few implementations of LSP for emacs, I've went through them before. The emacs-specific work for integrating LSP components is trivial.

I've considered rewriting jedhy to use the LSP. But the gains for Emacs users are minimal, rather it would enable pleasant Hy development for VSCode, vim, and others and centralize ide development.

Making Hy as pleasant as possible in Emacs specifically is my goal, and there is work I rate higher before a LSP rewrite.

If someone wants to write an LSP, I recommend working with me to refactor jedhy rather than start a project.

[markx]

nrepl seems to be more suitable for languages with repl. I think Clojure folks are also experimenting between lsp and nrepl. So maybe a combination of both?

[kaiuri]

It's possible to use nvim-treesitter's clojure parser, but you'll need to add hy as a filetype in filetype.lua.

--- filetype.lua
local filetype = vim.filetype
filetype.add {
    extension = {
        ['hy'] = 'hy'
    },
}

--- your treesitter configs
local ft_to_parser = require 'nvim-treesitter.parsers'.filetype_to_parsername
ft_to_parser.hy    = "clojure"

Forking the clojure parser and turning it into a hy parser is also an alternative.

[Kodiologist]

The linked issue in vim-hy was closed years ago. This should probably be closed too, and ultimately for the sake of organization further Vim-specific issues should be posted there.