## Description
<!-- Describe the big picture of your changes to communicate to the
maintainers
why we should accept this pull request. -->
`opts.diagnostics=false` was being ignored by `Snacks.picker.explorer`
## Related Issue(s)
<!--
If this PR fixes any issues, please link to the issue here.
- Fixes #<issue_number>
-->
I didn't create an issue for it
## Screenshots
<!-- Add screenshots of the changes if applicable. -->
## Description
From the docs on `:help vim.ui.select`
```
• {on_choice} (`fun(item: any?, idx: integer?)`) Called once the user
made a choice. `idx` is the 1-based index of `item`
within `items`. `nil` if the user aborted the dialog.
```
Right now the behavior will call `on_choice` if the user confirmed a
selection, but will not be called at all if the user explicitly or
implicitly closes the picker. As a plugin author, I rely on the
guarantee that if I call `vim.ui.select`, the callback _will_ be called
either with a value or with a nil.
I just added the simplest, dumbest possible fix for this that prevents
double-calling the callback.
## Related Issue(s)
N/A
## Screenshots
N/A
## Description
<!-- Describe the big picture of your changes to communicate to the
maintainers
why we should accept this pull request. -->
this adds an attribute for the range of the LSP symbol to each picker
item.
## Related Issue(s)
Fixes#1057
having access to the range of the LSP symbol (i.e. the whole context of
classes and methods) would be tremendously helpful for my solution in
https://github.com/folke/snacks.nvim/issues/1057#issuecomment-2652052218.
Currently the picker items only have a `loc` attribute which holds the
range of the symbol identifier, i.e. the class/method name.
---
perhaps in a followup we could use the range to highlight the symbol
context, similar to how trouble.nvim does it
## Screenshots
<!-- Add screenshots of the changes if applicable. -->
## Description
Adds a `opts.tree` boolean option for treesitter picker to toggle on/off
tree symbols
<!-- Describe the big picture of your changes to communicate to the
maintainers
why we should accept this pull request. -->
## Related Issue(s)
None, rather a discussion #1101
<!--
If this PR fixes any issues, please link to the issue here.
- Fixes #<issue_number>
-->
## Screenshots
<!-- Add screenshots of the changes if applicable. -->
