feat/ref(LSP): constructor variant better hover

[Wilbert-mad]

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.)

[GearsDatapacks]

Sounds good to me!

perhaps this should be split into a separate issue

There already is one for that part: #3507

Edit: looks like I misunderstood what was said. That issue is still relevant to this though

[lpil]

Sorry, I'm not sure what you're proposing here. Could you expand a little please?

Hovering a function doesn't currently return labels or argument names;

That function doesn't have any labels, so none would be shown. There's an issue for functions with labels here: #3507

Arguments are never shown as they are not part of the public API.

[Wilbert-mad]

In short what I'm proposing is to instead of showing the constructor name we show the construction variant, modulePath, and maybe its arguments. And what I'm wanting feed back on would be how that is formated. I've proposed the top is formated like ?<module.><CunstructorName> and then to the bottom of that op1, op2, or op3 For example, op1 is the easiest and follows c++'s lsp format of just showing the name and not its parameter or structure.

As for the function not showing labels I was making using of its formating to provide op2 which follows that. It doesn't contain argument name nor labels, but it appears labels are suppose to be shown and not arguments so to an extent op2 (given that fn should diplay lables and its just a bug their not) and op3 are the same showing their lables

[Wilbert-mad]

Here's and hypothetical hover (using the same code as shown in the proposal) for op3.
Hovering MatchEnd

gateway/ws_handler.SocketMsg
MatchEnd(
  reason: String,
  win_pid: Option(String),
  game_time: #(Int, Float)
)

For op2;

gateway/ws_handler.SocketMsg
MatchEnd(String, Option(String), #(Int, Float))

For op1;

gateway/ws_handler.SocketMsg
MatchEnd

[lpil]

Here's what the hover shows today on main. Rather than print the whole module name the local name for the type is used, whether qualified, aliased, or neither.

Beyond the labels, which there is an issue for, is there something you think is missing here?

[Wilbert-mad]

Right sorry I forgot that variants' hover alone does work, but where I've been focusing would be using this code;

case state {
  GameEnd -> todo
  MatchEnd -> todo
}

Hovering the variants here shows SocketMsg is that a bug or intentional? (Unless that's been fixed by the time I repulled main)

Secondly should variants lables be included that could also be a thing to work on?

[lpil]

It's not a bug, the type of GameEnd is SocketMsg just as the type of MatchEnd is fn(String, Option(_), #(Int, Float)) -> SocketMsg. You can hover over the arguments to see what their types are.

[Wilbert-mad]

Right, ok. How about the lables part then? That's being looked at for both functions and variants, right? And function argument names + lables or just lables?

[lpil]

Argument makes are deliberately not included, and there's an issue for labels.

[Norlock]

Any update on this? I think this is quite an important feature, now I just use the labelled argument in functions so I don't have to jump around in the code and be afraid I used a wrong arg somewhere.

[lpil]

What is an important feature, sorry?