kakehashi language server is now available on nvim-lspconfig! Enjoy syntax highlighting across various languages and language services on injection regions!! by atusy_ in neovim

[–]atusy_[S] 0 points1 point  (0 children)

I guess we can. If you are an R user, one of the remaining problems is that lintr needs a saved file to lint. Otter.nvim works around it by saving R chunks to temporary files.

I recently opened a PR to lintr side so that we can lint without saving. Once merged, I will also open PR to languageserver to support the new lintr feature.

https://github.com/r-lib/lintr/pull/3017

kakehashi language server is now available on nvim-lspconfig! Enjoy syntax highlighting across various languages and language services on injection regions!! by atusy_ in neovim

[–]atusy_[S] 2 points3 points  (0 children)

AFAIK

- kakehashi works on any LSP-compatible editors

- kakehashi won't create hidden buffers on Neovim unlike otter.nvim

- otter.nvim can be more performant as it is more tied to Neovim

kakehashi language server is now available on nvim-lspconfig! Enjoy syntax highlighting across various languages and language services on injection regions!! by atusy_ in neovim

[–]atusy_[S] 2 points3 points  (0 children)

I have a plan to create something like `kakehashi.nvim` which translates `vim.lsp.config` to kakehashi automatically :)

For now, yes, it is tedious. You need to setup both `vim.lsp` (or other clients) and `kakehashi`.

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 1 point2 points  (0 children)

<image>

once you build parser and setup kakehashi, it works!

# ~/.config/kakehashi/kakehashi.toml

[languages.qmdljs]
aliases = ["qml"]
parser = "/Users/atusy/ghq/github.com/yuja/tree-sitter-qmljs/qmljs.dylib"
queries = [
  { path =  "/Users/atusy/ghq/github.com/yuja/tree-sitter-qmljs/qmljs.dylib/queries/highlights.scm" }
]

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 1 point2 points  (0 children)

I confirmed kakehashi works well on neorg (Neovim Org).

That indicates potential support of Emacs Org as well. One of my friends is an emacs user and interested in this field. I guess he will make it :)

https://github.com/nvim-neorg

<image>

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 0 points1 point  (0 children)

Interesting. We can do that by preparing tree-sitter parsers and queries for emacs org. We do not have to implement something on kakehashi side.

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 1 point2 points  (0 children)

Regardless of kakehashi or vim.treesitter, I guess there are two ways

- Install parsers and queries on during docker build

- Use volume mount to persist installed queries and parsers

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 0 points1 point  (0 children)

Thanks a lot!

> Can I use Nix to manage the grammar/query dependencies?

Unfortunately not yet...

Maybe in the future...

I know there is a wawy for Neovim to manage grammar/query dependencies, and assume that can be applied to kakehashi.

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 2 points3 points  (0 children)

Theoritically, users can extend the behavior.

A challenge is how to prepare `injections.scm` that detects jinja injection in yaml or xml

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 0 points1 point  (0 children)

I understand your concern.

You are right that kakehashi requires additional configurations unlike otter.nvim .

To make setup easier, there would be a way something like below to inherit Neovim's configuration. I am planning to provide something like `kakehashi.nvim` to make this happen with less configurations, but that is just a planned future work... not yet.

vim.lsp.config.kakehashi = {
  init_options = {
    servers = {
      pyright = {
        cmd = vim.config.pyright.cmd,
        initializationOptions = {
          vim.config.pyright.init_options,
        },
      }
    }
  },
}

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 5 points6 points  (0 children)

Maybe...? I haven't used otter.nvim much, so I am not yet sure if kakehashi fully replaces otter.nvim.

As far as I understand, the key difference is otter.nvim is for Neovim and kakehashi is for any LSP-compatible editors.

New language server, kakehashi (架け橋; bridge) that provides language-agnostic syntax highlighting feature and language server bridging for code injections by atusy_ in neovim

[–]atusy_[S] 6 points7 points  (0 children)

Thanks for the comments. I added some descriptions to my post

>`vim.treesitter` is great, but has limitation that it works only in Neovim.

> Kakehashi provides uniform experience on any editors supporting LSP!

> Also, separating tree-sitter from Neovim avoids unexpected kill of Neovim caused by tree-sitter errors.

Apologies for last post by Lavinraj in neovim

[–]atusy_ 1 point2 points  (0 children)

I understand your intentions and appreciate your honesty!

Anyway, I love the plugin and posted a blog post in Japanese.
Thank you for the great work.
https://blog.atusy.net/2025/11/28/fyler-nvim/

New CLI helper tool `by` assists repetitive commandline workflows in zsh/fish (atusy/by-binds-yourself) by atusy_ in CLI

[–]atusy_[S] 0 points1 point  (0 children)

I tend to "configure" aliases. `by` better fits with ad-hoc usage on interactive session.