Problem
/// #(Minutes, Seconds)
pub type GameTime = #(Int, Float)
pub type SocketMsg {
@deprecated("little to no data provided")
GameEnd
MatchEnd(
reason: String,
win_pid: Option(String),
game_time: GameTime,
)
}
The code given above is in context for what is being hovered. Currently, when hovering a constructor's variant it will return the constructor type itself (SocketMsg). However, That provides really no data at all, I understand that you could to an extent achieve some access to the variant's fields by hovering .., and yes that is to an extent what I am proposing.
Current Hover:
GameEnd //or
MatchEnd
// ^Hover: SocketMsg // not much info
Proposed Idea
GameEnd
// ^Hover:
// ?<module.>SocketMsg
// GameEnd
MatchEnd
// ^Hover:
// ?<module.>SocketMsg
// NOTE: This is where things may start to differ from the current formatting of the LSP
// - i.e: Hovering a function doesn't currently return labels or argument names;
fn test(a: Int) -> Nil { .. } // Hover: `fn(Int) -> Nil` // instead of `fn test(a: Int) -> Nil`
// op1) MatchEnd // up to the dev to goto deff--similar to C++ lsp
// op2) MatchEnd(String, Option(String), GameTime) // similar to the current hover syntax (like functions)
// op3) MatchEnd(
// reason: String,
// win_pid: Option(String),
// game_time: GameTime,
// ) // different from the current hover syntax with more
//robust info--similar to perhaps other languages' LSPs like Rust, or Go
// clear example without all the comments--using op1
MatchEnd
// ^ Hover
// ?<module.>SocketMsg
// MatchEnd
variants' documentation would not change
Further info--Proposals;
op1 would be the quickest to implement as there has already been work done to have the type's module in the rust Pattern::Constructor. The only thing needed would be formatting.
op2 would also be relatively easy to format and gather the types from the arguments field and format like fn arguments.
op3 would require a bit more fidgeting as we'd need to create some fn(rust) in the printer to handle printing the labels of a constructor--something that in op2 can be replicated from printing fn in gleam.
Targeted changes
- Move hover behavior to its own contained file
/langauge_server/hover.rs
- Hovering variants should be more detailed
- Hovering variants' labels would provide the label type from the variant (perhaps this should be split into another issue? If not, I can expand on it here.)
Problem
The code given above is in context for what is being hovered. Currently, when hovering a constructor's variant it will return the constructor type itself (
SocketMsg). However, That provides really no data at all, I understand that you could to an extent achieve some access to the variant's fields by hovering.., and yes that is to an extent what I am proposing.Current Hover:
Proposed Idea
variants' documentation would not change
Further info--Proposals;
op1would be the quickest to implement as there has already been work done to have the type'smodulein the rustPattern::Constructor. The only thing needed would be formatting.op2would also be relatively easy to format and gather the types from the arguments field and format likefnarguments.op3would require a bit more fidgeting as we'd need to create somefn(rust) in the printer to handle printing the labels of a constructor--something that inop2can be replicated from printingfnin gleam.Targeted changes
/langauge_server/hover.rs