gopls有一个命令行界面，它以一种可以方便地从shell脚本或其他程序调用的形式暴露了许多有用的服务器功能(例如，显示分析诊断信息，重命名标识符)。由于我们不再支持较旧的单独CLI工具(例如，gorename),因此有理由认为它应该是一个一流的接口。然而，目前它名义上是“实验性的”。
本问题的任务是：
(a)大致了解有多少人使用当前形式的CLI工具。遥测应该使这变得容易。
(b)决定是否发布一组稳定、一致且文档良好的命令行操作，如果是这样，
(c)构建并记录它。
我们还应该考虑是否提供一个纯粹的LSP客户端(我猜这样的东西存在),它对gopls一无所知。这可能总体上工作量较小，并且可能更好地与标准客户端端的做法保持一致，尽管也有可能它更冗长、笨拙，或者无法轻松表达我们希望它能做的事情。
3条答案
按热度按时间vulvrdjw1#
我们已经为回归测试开发了一个无头LSP客户端(实际上，还有一个稍微不太健壮的无头客户端用于当前的命令行界面)。
我认为将其提取为通用的LSP服务器命令行界面会更有用。如果我们维护当前的CLI和回归测试，那么实际上我们就是在维护一个无头客户端，所以为什么不以更有用的方式共享它呢？
jq6vz3qz2#
我认为将其提取为通用的LSP服务器命令行界面会更有用。如果我们保持当前的CLI和回归测试，实际上我们就是在维护一个无头客户端，所以为什么不以更有效的方式共享它呢？
这当然会更有用，但我想知道谁会真正使用它，以及尝试保持严格服务器无关性或处理多个实际服务器的怪癖会带来多大的额外负担。它可能会让与gopls一起使用变得更加困难，而且由于位于单独的可执行文件中，可能会引入我们在当前方法中可以忽略的IPC或版本偏差问题。我不反对，但我们应该清楚地了解其中的成本和收益。
a0x5cqrl3#
我想象CLI的自定义功能也会对希望紧密集成的Go特定编辑器模式有用。也许可以将自定义行为保持为LSP操作(或它们被称为什么),这些可以在gopls CLI上作为“原生”操作呈现，但仍然可以从通用LSP客户端访问。如果你尝试在非gopls服务器上使用这些自定义操作之一，你将得到一个
<whatever> action not supported错误。