Enabling tree-sitter for with Nix gives a "Query pattern is malformed" error

[aciceri]

I'm trying to add support for the nix-ts-mode. I'm using the grammar from nixpkgs unstable which should corresponds to this commit. It's not the latest version but I can't see any change to the grammar itself in next commits.

My indent-bars-treesit-wrap is '((nix list_expression)). Changing it with '(python list) perfectly works for python-ts-mode so I'm quite sure I'm doing everything else correctly.

When I type M-x indent-bars-reset I get the following error:

indent-bars--current-indentation-depth: Query pattern is malformed: "Node type error at", 3, "[(string)] @s", "Debug the query with `treesit-query-validate'"
Error in post-command-hook (indent-bars--highlight-current-depth): (treesit-query-error "Node type error at" 3 "[(string)] @s" "Debug the query with `treesit-query-validate'")

I'm using this source:

{
  foo = [
    1
    2
    3
  ];
}

This is the tree according the explorer:

expression: 
 (attrset_expression {
  (binding_set
   binding: 
    (binding
     attrpath: (attrpath attr: (identifier))
     =
     expression: (list_expression [ element: (integer_expression) (integer_expression) (integer_expression) ])
     ;))
  })

What really concerns me and made wonder if this is really indent-bars' fault is the list_expression node containing only one named child node element: (integer_expression). Or perhaps I'm misunderstanding the DSL and all the nodes after element: are named that way? Assuming that this has nothing to do with indent-bars I'm also worried that the problem lies in the tree sitter integration with emacs since I know for sure that this grammar is used by helix and neovim. So it sounds implausible such a serious problem.

Anyway also the error "query pattern malformed" is weird so it could be also indent-bars. Oh I'm using the latest commit currently on master.

[jdtsmith]

You should disable indent-bars-no-descend-string, or set it to a valid string type (after updating to the version I just pushed). Unfortunately there are very few commonalities among language grammars, i.e. strangely enough 'string is not a valid node-type in many. I had assumed I could hard-code that, but no such luck.

[jdtsmith]

Added a test that at least throws a useful message and disables the feature.

[aciceri]

It works setting indent-bars-no-descend-string to nil, thanks! Now I wonder what nodes I should wrap because to be fair if the source is correctly indented (according to its tree sitter indent rules) I can't think any situation where wrapping makes sense. And I don't believe I should target situations where indentation is incorrect.

[jdtsmith]

It doesn't cause wrapping to occur, it just inhibits extra bars in elements that do not align on indentation boundaries when they span multiple lines. Function call/definition argument lists are the classic example. You don't have to use treesitter. I'd start by leaving indent-bars-treesit-wrap=nil, then if you discover cases where extra bars get inserted (either by experiment or reading the indent rules), look at what node is the one causing that wrapping.

[aciceri]

I was already using indent-bars without tree-sitter support but since I was playing with tree-sitter I decided to try it out. I realized only later that I didn't have any real situation with too many bars.

either by experiment or reading the indent rules

I'm the one writing them! There is one fork for nix-ts-mode that have them but they don't cover many cases, I was trying to improve the situation.

The alternative for me would be matching all nodes for nix in indent-bars-treesit-wrap. Would it make sense? Assume that in well indented nix code you never have extra bars even without tree-sitter enabled in indent-bars. At this point it would make also sense that if one manually indented nodes more than what indent rules say then extra bars are not showed. Thinking again about it I don't think that matching everything would work... Is it possible that some bars are hidden on a line because of indent-bars-treesit-wrap and then they start again normally on the same line further to the right?

I've tried creating an ASCII art example but it's probably even more confusing.

Anyway thanks again for the great package!