Closed b0o closed 4 months ago
I'm not sure how otter.nvim is expecting range formatting to work (or even how it is supposed to work in LSP). Is it running range formatting on the TypeScript file, but only on the lines containing the GLSL snippet? If so, I could probably hack together a solution that would work for you: just run a formatting request on the given range, assuming the range is a full file. However, this is likely something that is easier to do from within otter.nvim, as it already has the entire snippet in a separate buffer. There are probably other LSP-servers that don't implement range formatting, so it's likely best to start there.
Also, I'm not sure how range formatting should be implemented in general: what if the range only partially covers a syntax node? For example, if a formatting request is issued on the first half of a function, should the remainder of the function be left as-is?
This issue seems related: https://github.com/jmbuhr/otter.nvim/issues/14
First, thank you for your work on this project, it's been a very helpful tool!
I'm using glsl_analyzer in Neovim, primarily for embedded glsl code blocks inside of other languages. For example, inside a TypeScript file:
I'm using treesitter parsers for both TypeScript and GLSL. The TypeScript treesitter parser supports injected code blocks using tagged template literals as I've demonstrated above. Then, I'm using otter.nvim which lets you run LSPs on these embedded code blocks.
In this way, LSP autocompletion and hovering works perfectly. One drawback is that otter.nvim seems to need the attached LSP to support
textDocument/rangeFormatting
in order to format the code blocks, so I'm unable to use glsl_analyzer for formatting with my setup. Adding range formatting support should fix this.