Unimplemented pinned datatips and modifier providers

[illright]

In the types for atom-ide-datatip, there are two unimplemented concepts:

• a pinned datatip (presumably, a datatip that stays at a particular position in the editor until dismissed manually)
• a modifier provider (presumably, a provider that is also passed the information about the held modifier keys like Ctrl or Shift)

What would be the use cases for these? So far I don't see much reason to have them. They aren't implemented by the LSP, so it's unlikely that we'll have proper language support for these either.

[lierdakil]

These are GUI features, those aren't related to LSP at all. A pinned datatip is a datatip that stays in place even without a mouse hovering over it. Here's a picture to hopefully make it clear(er):

Having dedicated pinned datatips can be useful to cater to keyboard warriors out there, who don't want to touch the mouse -- if a datatip is invoked via keyboard, it should by definition be pinned as far as I gather.

Disclaimer: I didn't take a look atom-ide-datatips.

As for modifiers, honestly I'm not sure if anything in fact implements those, but those could be useful in some contexts actually. For instance, in Haskell, you could show either computed or declared type (which are distinct because of parametric polymorphism) -- using a modifier key to choose one or the other can be convenient (and "why not both" -- because some -- actually many -- people like to see only what they need, not everything at once). The Provider would have to use some trickery to make it work of course, but it's not complicated.

[illright]

The reason I'm mostly talking about LSP is because I frankly believe no one's going to develop language tools for Atom (at least for a while), so having language features coming from LSP seems to me as Atom's greatest hope. LSP doesn't support modifier keys for now, so perhaps we could remove this feature from the interface (so that TypeScript wouldn't scream at us for not implementing it) and maybe implement it in the future, in the bright days of Atom.

I got your point about how keyboard-activated datatips should be pinned, however, it brings a question – what is the best way to dismiss them without touching the mouse?

[lierdakil]

what is the best way to dismiss them without touching the mouse?

escape. Depending on preference, either all of them, or one by one in the reverse order of appearance. I could live with either, but an option might be nice.

no one's going to develop language tools for Atom

I am developing language tools for Atom. Well, maintaining mostly, but that's beside the point. I'd love to get rid of some clunky cruft I made in atom-haskell back when there wasn't atom-ide, in favour of a more "standard" ide interface, but by the time I had time to do it, atom-ide was discontinued, so now I'm kinda stuck in a limbo not doing anything (also I really need to add LSP support there, but spare time has been a bit of a luxury in the past couple years). And I'm also maintaining atom-typescript, and TypeScript also doesn't do LSP. So, not the most comprehensive list, but it's not trivial, I think?

[illright]

Oh, okay, that is good to know

TypeScript doesn't do LSP

What do you mean by that? There isn't a language server for TypeScript or that atom-typescript isn't powered by LSP?

[lierdakil]

There isn't an "official" LSP-compliant language server for TS. Tsserver, which is part of the TypeScript compiler, isn't LSP-compliant in the slightest. There are some hacks out there, which provide an LSP-compliant wrapper around tsc, and they kind of work, but aren't amazing (for instance https://github.com/theia-ide/typescript-language-server is still based on TS 3.9, so two releases behind, and there are some additional quirks on top of that). So yeah, "TypeScript team doesn't do LSP" is probably the accurate statement here.

[aminya]

Yeah, these are GUI features. We can make the types optional.

[aminya]

I have WIP PR which tries to add FloatPane support. The branch is very out of date. I can look into updating it. But this is low-priority.

#27

[aminya]

The types were fixed in #45