Ruby indents braces ({) incorrectly inside a method

[hectron]

Describe the bug

When writing Ruby code with Treesitter's indent functionality enabled, typing an open brace { indents it all the way to the beginning of the line. Other characters, such as an open paren or an open bracket do not have this problem.

Screen.Recording.2024-02-16.at.5.58.31.PM.mov

To Reproduce

1. Use the following Treesitter config:

require'nvim-treesitter.configs'.setup {
  ensure_installed = { "ruby" },
  highlight = {
    enable = true,
  },
  indent = {
    enable = true
  },
  endwise = {
    enable = true
  }
}

2. Run :TSUpdate
3. Open up a ruby file (e.g. sample.rb)
4. Write a method
5. Insert a left brace {
6. Insert a right brace }

Expected behavior

The left brace should not indent to the left, and instead should be indented to the right.

Output of :checkhealth nvim-treesitter

──────────────────────────────────────────────────────────────────────────────
nvim-treesitter: require("nvim-treesitter.health").check()

Installation
- WARNING tree-sitter executable not found (parser generator, only needed for :TSInstallFromGrammar, not required for :TSInstall)
- OK node found v12.14.0 (only needed for :TSInstallFromGrammar)
- OK git executable found.
- OK cc executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
  Version: cc (Debian 10.2.1-6) 10.2.1 20210110
- OK Neovim was compiled with tree-sitter runtime ABI version 14 (required >=13). Parsers must be compatible with runtime ABI.

OS Info:
{
  machine = "x86_64",
  release = "5.10.0-28-cloud-amd64",
  sysname = "Linux",
  version = "#1 SMP Debian 5.10.209-2 (2024-01-31)"
}

Parser/Features         H L F I J
  - bash                ✓ ✓ ✓ . ✓
  - c                   ✓ ✓ ✓ ✓ ✓
  - cmake               ✓ . ✓ ✓ .
  - diff                ✓ . . . .
  - dockerfile          ✓ . . . ✓
  - git_config          ✓ . ✓ . ✓
  - git_rebase          ✓ . . . ✓
  - gitcommit           ✓ . . . ✓
  - gitignore           ✓ . . . .
  - go                  ✓ ✓ ✓ ✓ ✓
  - groovy              ✓ ✓ ✓ ✓ ✓
  - hcl                 ✓ . ✓ ✓ ✓
  - html                ✓ ✓ ✓ ✓ ✓
  - http                ✓ . . . ✓
  - java                ✓ ✓ ✓ ✓ ✓
  - javascript          ✓ ✓ ✓ ✓ ✓
  - jq                  ✓ ✓ . . ✓
  - json                ✓ ✓ ✓ ✓ .
  - kotlin              ✓ ✓ ✓ . ✓
  - lua                 ✓ ✓ ✓ ✓ ✓
  - luadoc              ✓ . . . .
  - markdown            ✓ . ✓ ✓ ✓
  - markdown_inline     ✓ . . . ✓
  - properties          ✓ ✓ . . ✓
  - proto               ✓ . ✓ . .
  - puppet              ✓ ✓ ✓ ✓ ✓
  - python              ✓ ✓ ✓ ✓ ✓
  - query               ✓ ✓ ✓ ✓ ✓
  - ruby                ✓ ✓ ✓ ✓ ✓
  - rust                ✓ ✓ ✓ ✓ ✓
  - sql                 ✓ . . ✓ ✓
  - ssh_config          ✓ ✓ ✓ ✓ ✓
  - terraform           ✓ . ✓ ✓ ✓
  - toml                ✓ ✓ ✓ ✓ ✓
  - typescript          ✓ ✓ ✓ ✓ ✓
  - vim                 ✓ ✓ ✓ . ✓
  - vimdoc              ✓ . . . ✓
  - yaml                ✓ ✓ ✓ ✓ ✓

  Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
         +) multiple parsers found, only one will be used
         x) errors found in the query, try to run :TSUpdate {lang}

Output of nvim --version

NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/__w/neovim/neovim/build/nvim.AppDir/usr/share/nvim"

Run :checkhealth for more info

Additional context

No response

[hectron]

For what it's worth, I have my desired indenting sort-of working through a variety of trickery.

First, I use RRethy/nvim-treesitter-endwise to open and close my parens, braces, brackets and end statements. This is enabled via my treesitter config.

Next, I disable indenting on Ruby files, but enable vim regex highlighting for Ruby:

require'nvim-treesitter.configs'.setup {
  ensure_installed = { "ruby" },
  highlight = {
    enable = true,
    additional_vim_regex_highlighting = { "ruby" },
  },
  indent = {
    enable = true,
    disable = { "ruby" },
  },
  endwise = {
    enable = true,
  }
}

[lucario387]

This sounds like a parser precedence stuff. Of course we can somewhat contain this with (ERROR) node handling. But that will be dangerous