您的功能请求是否与问题相关？请描述。
后缀代码片段的引入为gopls带来了非常方便的功能，尤其是在Goland之外的工作场景中。我想为gopls贡献更多基于已有编辑器功能的后缀补全建议。特别是，我想提议添加一个if!提示符和一个not!提示符，它们分别执行以下操作：
(complex bool expression).if|
if (complex bool expression) {
|
}
(expr).not|
!(expr)描述您希望实现的解决方案
在completion/postfix_snippets.go中实现这些功能。
描述您考虑过的替代方案
作为一名vim开发者，我个人使用snippetsEmu。其他潜在的替代方案可以在VSCode和Goland中找到。
9条答案
按热度按时间rt4zxlrg1#
CC @muirdm.
tpgth1q72#
感谢您的建议。缪尔可能对此有一些想法。
nhaq1z213#
想要补充的是，我们可以通过处理类似
==、>=、^等事物来完全过度工程化not,但我个人认为这是杀鸡用牛刀。大多数时候(至少对我来说),这种方法有用的地方只是否定一个布尔变量或一个由括号包围的复杂布尔表达式。在我看来，对于边缘情况：
应该扩展为
这有助于使自动补全代码片段更轻量级，如果用户非常希望如此，他们可以通过将表达式用括号括起来或手动更改来获得该功能。
dgjrabp24#
if!代码片段听起来合理，但您需要做一些工作，使a == b.if!作为(a == b).if!处理(即应用于整个语句，而不是选择器表达式)。您还可能会遇到关键字if作为选择器的问题。我对
not!代码片段不太确定。如描述的那样，它只会应用于布尔表达式，因此例如在if a == "foo".not的情况下不会起作用。如果它在那种情况下起作用，那么在更复杂的情况下，如if (a == b) == (c == d).not中，预测它会做什么就会变得困难。Goland 是否提供 "not" 代码片段？krcsximq5#
我认为这不需要经过提案过程，所以将其移除。如果您不同意，请发表评论。
du7egjpx6#
你可能还会在使用关键字
if作为选择器时遇到问题。抱歉，我不太确定我在这里的意思。
Goland 对这些代码片段的实现实际上有点复杂。当存在模糊的情况，比如 "a == b.not!",它会显示一个上下文菜单，让用户选择是只做第一部分，还是整个事情：
根据我的理解(如果我错了请纠正),目前在 gopls 中还不可能实现，所以我认为除非你有关于如何绕过这个问题的建议，否则抛弃 .not 代码片段是合理的。
at0kjp5o7#
你在使用关键字作为选择器时也可能会遇到问题。
对不起，我不太确定我在这里的意思。
Go解析器在关键字出现在意外/无效的地方时会有困难(例如
foo || bar.if中的 "if")。Gopls有一个解决方法，试图将 "foo.if" 解析为一个普通的标识符，而不是一个if语句，但我不确定它在新代码片段的情况下是否有效。根据我的理解(如果我错了请纠正),在gopls中是不可能实现的。LSP代码片段有选择，可能会允许类似的体验。但更简单、更好的方法可能是让gopls提供多个补全候选项，每个选项对应一个可能性。
无论如何，我会先跳过
not,从if开始，因为它似乎更有用且更直接。jyztefdp8#
听起来不错。我会尝试一下。如果我遇到任何困难，我会回来报告的😄
pxiryf3j9#
你是否仍在处理这个问题？