Proof of concept: Diagrams plugin #3250
Conversation
| return Nothing | ||
| where | ||
| looksLikeDiagram :: IDE.Type -> Bool | ||
| looksLikeDiagram = ("Diagram" `isPrefixOf`) . IDE.printWithoutUniques |
There was a problem hiding this comment.
Do we not at least have the qualified name here?
| aux :: GHC.NoCompat.Module -> UTCTime -> GHC.Linkable | ||
| aux mod time = GHC.LM time mod [] | ||
|
|
||
| initialiseSessionForEval :: |
There was a problem hiding this comment.
Can these bits be shared with the eval plugin? It looks like you already depend on it. GHC session management is fiddly at the best of times, it would be great if we can deduplicate it!
There was a problem hiding this comment.
I was going to ask the same thing. The Eval plugin already contains code to do interactive evaluation, so I think it would be best if hls-diagrams-plugin reused more of it!
| Example diagram | ||
| -------------------------------------------------------------------------------} | ||
|
|
||
| _myCircle :: Diagram B |
| deriving stock (Show) | ||
| deriving anyclass (Exception) | ||
|
|
||
| newtype CatchErrors c m a = CatchErrors { |
There was a problem hiding this comment.
would be nice to have some explanation of what this is for, etc. It looks like you're halfway to writing a generic plugin handler monad, which would be no bad thing!
There was a problem hiding this comment.
This looks good to me, modulo the code sharing with the Eval plugin. I'm happy to merge it as soon as you update the docs to list the new plugin. In particular:
- update
docs/features.md - update
docs/supported-versions.md - add yourself to the CODEOWNERS file,
Thankyou!
| aux :: GHC.NoCompat.Module -> UTCTime -> GHC.Linkable | ||
| aux mod time = GHC.LM time mod [] | ||
|
|
||
| initialiseSessionForEval :: |
There was a problem hiding this comment.
I was going to ask the same thing. The Eval plugin already contains code to do interactive evaluation, so I think it would be best if hls-diagrams-plugin reused more of it!
|
I'm happy to make those changes, but then we should wait for the dust to settle on #3249 first I guess. Also, if we are going to merge this,perhaps I should make a minor modification: instead of recognizing -- hls:renderimage
myImage :: FilePath -> IO ()
myImage = ... rendering code ...or some such, so that we generalize away from I also need to add a handle to clean up the temporary files on exit, I will do that too, along with the other suggestions. But yes, let's wait for Matt's eval simplification PR first (this was written in parallel to that last week). |
|
Sorry, I just realized that there is an obvious better way to do have the generalization without causing security exploits. The above signature is too general; we should just have -- hls:renderimage
myImage :: ByteString
myImage = .. rendering code ..or something like that. |
|
I'll close this PR for now, since I don't really have time to update it. If someone feels inspired by it and wants to take it over, please feel free :) |
This PR adds a proof-of-concept plugin that can render diagrams when hovering over a (top-level) binding of the appropriate type.
Perhaps it would be nicer to generalize this over some kind of custom
Rendertype class, but that might get a bit messy dependency wise (where would thatRendertype class be defined)?It would also be much nicer if the diagram would be shown inline as a code lens rather than on hover, but it seems this is not possible with LSP?
With many thanks to @wz1000 and @mpickering !