You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 7, 2020. It is now read-only.
[12:24am] lukelau: alanz: I was reading that earlier, does brittany do that type of formatting?
[12:25am] lukelau: I agree though, it would be a great example plugin
[12:25am] lukelau: I think the VFS is stored inside haskell-lsp’s LspFuncs
[12:25am] lukelau: Which is only in the reactor monad
[12:27am] lukelau: I feel like a lot more of the stuff inside LspFuncs should be inside IdeM
[12:27am] lukelau: Since CodeActionRequest is already having to manually pass through the project root, which is in LspFuncs
[12:27am] lukelau: And the same goes for client capabilities
[12:28am] lukelau: It would also be nice to have the client config available as well, it would unblock that brittany PR
[12:30am] lukelau: Just from looking at https://hackage.haskell.org/package/haskell-lsp-0.8.0.0/docs/Language-Haskell-LSP-Core.html#t:LspFuncs, everything except for sendFunc, publish/flushDiagnostics and getNextReqId could be in IdeM
[12:32am] lukelau: Maybe we should separate it out into the “internal” functions and stuff that is shared in IdeM
[12:33am] lukelau: To answer your question though, I’ve been using GM.withMappedFile file inside HsImport
A CodeActionProvider call, and a Plugin Command should have functions along the lines of
which accesses the current contents of the VFS, and returns the fragment within the given range, if it exists.
The return value could be an list of lines, or a single Text string, whichever makes sense.
The text was updated successfully, but these errors were encountered: