首先，明确 LSP hover request params 中的 position，它是当前被 hover 的 character 左侧的 gap 所对应的位置，详见 microsoft/language-server-protocol#2184

把 LS 与 CodeEditor 视作一个整体，符合直觉的 hover 行为可能是这样的：当某个 character 被 hover 时，应当展示包含该 character 的某个“语法单元”对应的信息；不过在“包含”的判定上，不同的 LS 实现有所差异（可能有用户体验的考量，也可能有逻辑复用的原因），这里以 Typescript 和 Golang 官方 language server 实现为例进行说明。

Typescript

Typescript 会对 identifier、keyword 等特殊内容末尾的 character 做特殊处理，当 hover 在该 character 上时，会返回 character 前的内容的信息。例如对于 console.log(123)，当 hover 在 ( 时，会返回 console.log 的文档。

具体逻辑见 getTouchingPropertyName
对应的引入该逻辑的 PR make rename\gotoDef work at the end of token microsoft/TypeScript#752

从该 PR 的标题来看，它针对的大概是这样的情况：光标挪到了某个 identifier 末尾的位置，然后通过键盘进行 rename / gotoDef 的操作，支持这样的操作是很合理的

Go (gopls)

gopls 在跟 Typescript language server 在很多情况下类似，如当 identifier 后的 character 被 hover 时，会返回该 character 前的 identifier 对应的信息。对应的代码在 Cursor.FindByPos，注意这里的结果是 n.Pos() <= start && end <= n.End() 的 node，当 node.End() == end 时，hover 就发生在紧跟在 node 后的一个 character 上。不过暂时没找到关于这个行为的 issue 或讨论。

除此之外，还会有一些其他的特殊逻辑，比如对于 *types.Var，当 hover 到 * 时，会返回 types 的信息。

总结

综上，不同的 LS 实现在处理 hover 行为时，对于 identifier 等内容边缘的字符处理存在差异，且大部分会对 identifier 等内容之后的字符返回 identifier 对应的内容。如果认为这样的行为确实存在“不符合直觉”的地方，已知的原因主要是给键盘和鼠标同时提供良好的体验。

Inconsistent hover card actions across multiple hover attempts #2043

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions