golang indent issues when auto-pairs = false

[salarkhan]

Summary

when writing expressions, i expect an outdent when i input the matching pair. in some cases, the closing brace is in line with the content of the expression:

in other cases like creating a function, i expect an indent after opening the brace and hitting enter, yet it does not.

all of these scenarios are resolved if i close the braces immediately, and then fill in the content.

Reproduction Steps

https://github.com/helix-editor/helix/assets/3118416/951eeddb-8826-4c03-ade0-3cdd182f1e1d

Helix log

No response

Platform

macOS

Terminal Emulator

kitty 0.28.0

Helix Version

helix 23.05

[woojiq]

Iirc that's how a tree-sitter works. This is not specific to golang. If you select your function without the closing brace and run :tree-sitter-subtree you will see that there is an error when parsing the source code. This is why indent-queries don't work well in this situation.

Edit:

As you can see in the second example, there is no Block node that is used to increase the indentation by 1. https://github.com/helix-editor/helix/blob/929eb0c39e34f8046b5ec9ecfede4ec80b5e0c8a/runtime/queries/go/indents.scm#L16

[woojiq]

Probably duplicate of https://github.com/helix-editor/helix/issues/6044

[pascalkuthe]

Yeah the closing bracket not causing a decent without autopairs is both known and expected and would be covered by #6044.

For the error nodes causing indents we do sometimes work around situations like this by also matching error nodes in the tree sitter indent captures.

CC @Triton171

[Triton171]

I think at least for simple scenarios it should be possible to fix this my matching error nodes. A possible pattern would be:

(ERROR
    "{" @indent @extend
)

This correctly indents a function even if the closing } is missing. However, an incomplete if statement inside the function is not indented correctly. Finding queries that work correctly for multiple incomplete nesting levels seems non-trivial since the tree-sitter grammar behaves weirdly in these cases. If you experiment a bit and look at the syntax tree (using the :tree-sitter-subtree and :tree-sitter-scopes commands), you might be able to find queries that cover most of the common situations though.