Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selecting sibling nodes with more specificity #6

Open
dbernheisel opened this issue Aug 19, 2024 · 1 comment
Open

Selecting sibling nodes with more specificity #6

dbernheisel opened this issue Aug 19, 2024 · 1 comment

Comments

@dbernheisel
Copy link

Given some TreeSitter nodes that classify a lot of things similarly, such as the example below with Elixir with both alias ... and def my_function being parsed as "call" nodes, it doesn't look like tssorter will allow me to select nodes that satisfy a list of conditions and will grab too many unrelated siblings in the AST to sort. In my case, I'm trying to only sort the alias lines, not the def lines.

There's a couple solutions I can think of, LMK what you think:

  1. Allow :TSSort to accept a range to sort within, so I can visually select the block of aliases, and TSSorter only regards those.
  2. Allow config to specify conditions on the node somehow. In Scheme,
image image

my config, using lazy.nvim:

{ 'mtrajano/tssorter.nvim',
  -- latest stable version, use `main` to keep up with the latest changes
  version = '*',
  config = function()
    local tssorter = require('tssorter')
    tssorter.setup({
      sortables = {
        elixir = {
          alias = {
            node = 'call',
            ordinal = 'arguments'
          },
          alias_group = {
            node = 'alias'
          }
        }
      }
    })
@mtrajano
Copy link
Owner

Interesting that those two types of nodes are considered call nodes in Elixer. To me it seems like it should be two different types of named nodes, but that's besides the point, and I'm not an Elixer dev so I can't say for sure why it was done that way. I do have the ability to sort nodes in a visual selection/range as one of the things on my todo and it's something I'm going to be working on soon. That should resolve the problem you're having. I can ping here once that change is out.

I think your other suggestion to have the ability to configure some sort of condition/filter for whether a node should be considered sortable is also interesting but I'm afraid of adding unnecessary complexity. For now the ability to sort a range should do the trick and fix the issue you are having. It could be something worth exploring in the future, would just need to see some more use cases where it's needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants