Improving LSP Compatibility: Setting buffer extension based on filetype, and don't write file to disk

[quarkw]

I've been trying to setup LSPs with firenvim.

One particular issue I've run into with omnisharp/csharp, is that the LSP server will refuse to attach to the buffer the buffer name doesn't have the right file extension. In most cases, the file extension will be txt, and I've seen it defaulting to c in some code editors.

I believe if the filetype is changed like :set filetype=cs, if we were to rename the buffer as well, this would be beneficial to LSP compatibility.

Another issue is that omnisharp, and maybe other LSP servers parse any other files of the same filetype in the PWD. All of the files created by firenvim end up polluting the namespace and cause compiler issues, interfering with the ability of the LSP server to provide any meaningful information to neovim.

One solution I have to that is to actually delete the file when entering the buffer au BufEnter * ++once call delete(expand('%'))

For saving, I have a debounced version of essentially au TextChanged,TextChangedI * ++nested silent update

I think because I'm using update, the file never actually gets written again but the text field does get updated properly, and LSP completions work perfectly for me that way

[glacambre]

Hi, thanks for using Firenvim and for taking the time to explain your problem in depth :).

I think because I'm using update, the file never actually gets written again but the text field does get updated properly

No, what is missing is the BufWrite autocommand Firenvim creates for the buffer, which notifies Firenvim each time the buffer is written. That's this piece of code:

https://github.com/glacambre/firenvim/blob/668b350ce88cc9a2257644c67945c9abbdd36cb5/src/input.ts#L97-L115

If you manually create this augroup after the buffer is created, replacing ${chan} with the result of filter(nvim_list_chans(), {k,v -> has_key(v, "client") && get(v.client, "name", "") == "Firenvim"})[0].id, Firenvim should start being updated when the buffer is written.

I guess it would probably make sense to turn this into a vimscript function that people could call whenever they decide they need to setup their own buffer. While this would be very easy to implement, I can't publish any new versions of Firenvim on the Chrome and Firefox add-on stores before https://github.com/glacambre/firenvim/issues/1193 is closed unfortunately, so that change will take a long time before reaching you.

If you always want to use C# on the same domain, there might be another workaround: you could set the filename localSetting to something like {hostname%32}_{pathname%32}_{selector%32}_{timestamp%32}.cs, which will ensure that the filename Firenvim uses for that domain always ends in .cs.

Let me know what solution you chose and how it goes :)

[quarkw]

I actually am already manually setting the filename per host for now as a workaround, but thanks for the suggestion.

Also, my comment about the file not being written actually wasn't a complaint. That's actually the desired functionality for my usecase, as it keeps the namespace for the csharp/omnisharp LSP server from being polluted. Firenvim is still updating the textfield appropriately.

Thanks for the great extension, by the way! It's very nice being able to use actual vim in the browser :)