# editor: Honor \`lsp_results_location\` on cmd-click \(\#64039\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/59adbbe8b96dfff4ee9ce25e18681f8189904f70)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 59adbbe8b96dfff4ee9ce25e18681f8189904f70

Requested commit: 59adbbe8b96dfff4ee9ce25e18681f8189904f70

Commit: 59adbbe8b96dfff4ee9ce25e18681f8189904f70

Tree: 2e503ff156a573001699dc9e44d1d06221e08bf6

Author: Vitalii Shevtsov

Committer: GitHub

## Message

```
editor: Honor `lsp_results_location` on cmd-click (#64039)

# Objective

Fixes #62916.

With `"lsp_results_location": "picker"`, `cmd-b` opens the LSP locations
picker but cmd-clicking the same symbol still opens a `Definitions for
…` multibuffer. #61187 fixed this for the go-to-definition *fallback*;
the definition path itself was left behind.

The setting is only consulted by `handle_nav_action` in `lsp_locations`,
which runs when one of the navigation *actions* is dispatched. Cmd-click
never dispatches them: `cmd_click_reveal_task` either navigates the
cached hover links itself, or calls `go_to_definition_of_kind` /
`go_to_type_definition` directly.

## Solution

Both cmd-click paths now dispatch the matching action (`GoToDefinition`,
`GoToTypeDefinition`, …) when `lsp_results_location` is `picker` and the
click is not a split one, so the picker gets its chance; everything else
is untouched:

- with the default `multi_buffer` setting `picker_action` returns `None`
and the old code runs unchanged;
- alt (split) clicks keep their current behavior, since the split
actions have no picker handler;
- URL and file links keep opening directly — the action is only
dispatched when every resolved link is a `HoverLink::Text`.

The dispatch is deferred to after the current editor update via
`cx.spawn_in`: `LspLocationsPicker::open_for_editor` reads the editor,
so dispatching inline panics with `cannot read editor::Editor while it
is already being updated` (this is also why the existing fallback
dispatch happens from a spawn).

## Testing

`cargo test -p lsp_locations` — two new tests, one per cmd-click path: a
cold cmd-click, and a cmd-click on a link already resolved by hovering
with the modifier held (the path users actually hit). Both fail on
`main` with the fix reverted and pass with it.

Also ran `cargo test -p editor --lib hover` (68 passed) and `cargo
clippy -p editor -p lsp_locations --all-targets`.

Not yet verified by hand in a running Zed build — the automated tests
above are what backs this.

## Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable


## Release Notes:

- Fixed cmd-click on a symbol ignoring the `lsp_results_location`
setting: with `"picker"` it opened a definitions multibuffer instead of
the picker that `cmd-b` opens
([#62916](https://github.com/zed-industries/zed/issues/62916)).

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>
```

## Parents

- [52e0b848dafed5d59a7634995b8b7021672dc5ab](https://git.cafe/gitcafe/zed/commit/52e0b848dafed5d59a7634995b8b7021672dc5ab?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/59adbbe8b96dfff4ee9ce25e18681f8189904f70?format=markdown)
