Add LSP doc

[Amzd]

This PR adds doc for how to get code completion for strudel functions. Sadly this only works in .js, .mjs, .ts file extensions (maybe some more js related extensions) as otherwise the LSP does not give suggestions for code from the same module.

[gruvw]

Interesting proposal for that feature, thank you for taking the time. I am not sure however that I want to include it if partially completed. I think we need it on .str files as well.

[Amzd]

The typescript lsp does not give autocomplete in this way in non-js files. I do not know how to fix that.

[kentkr]

@gruvw @Amzd thank you both for the plugin and the tutorial to compile the docs. It works great w/ .js files.

Is there an inherent benefit of .str files? I'm not a js person so any idea why completion won't work on .str? I spent a decent amount of time trying to trick my lsp to see .str as javascript file types, but to no avail

[jdillard]

I think you can use vim.filetype.add()? Example:

-- Add this to your init.lua or in a filetype.lua file
vim.filetype.add({
  extension = {
    str = 'javascript',  -- or 'typescript' depending on your preference
  }
})

[Cae-lim]

From what I can tell lack of .str support is an issue with the TypeScript lsp that you see a lot in projects that use a modified version of another language (e.g. using html like templating languages such as ejs). This doesn't seem like an issue the contributor can fix since the solution is to use something like filetype.add or your lsp config to tell nvim to treat .str files as .js files (unless you want to write your own lsp from scratch).

[gruvw]

unless you want to write your own lsp from scratch

That could be a solution.

I currently have two issues with this feature/PR:

1. It only works for JS/TS files (indeed might be outside of our control)
2. The user has to generate the completion files and only stay in that directory

I am not a fan of shipping the LSP feature with these two problems. It's more of a workaround for the moment.

I think writing a small LSP could maybe fix both of these issues and give us more control.
Is there an easy way we could wrap or fork an already existing JS/TS LSP?

Thoughts?

[Amzd]

1. I cannot fix this
2. Do you want to bundle the .d.ts in this repo?

[gruvw]

1. I know
2. No, it doesn't change the problem

[IhsenBen]

Since the limitation comes from the TS LSP and isn’t fixable inside the plugin, would it make sense to merge this as “optional docs for users who want autocomplete today”, while a proper .str LSP stays on the roadmap?

[gruvw]

I'm not sure that this workaround should be part of the plugin's repository, as I don't personally like this solution. I think it's fine to leave the PR as is for people that want to dig into workarounds and setup an LSP, but I would rather go straight up and motivate a few people to work on an actual solution instead.

I am currently doing many other things, so I can't take the time to develop that rn but I certainly will in the future if nobody else does it before :)