Implement Vim's tag stack#46002
Conversation
|
Ooh actually that test failure seems important, taking a look |
|
The first commit changes the semantics of splitting panes to also fork nav history. That appears to be upsetting some of the assumptions the |
This change is hopefully mildly useful for everyone (you can now use splits to "explore" history without risking giving up on your current state), and will be very helpful in a few moments for implementing the Vim tag stack
Implement a Vim-like tag stack for Zed. We keep an extra stack of `(origin, target)` pairs in navigation history. Every go-to-definition (and similar, e.g., ctrl-clicking an identifier) pushes an entry onto the tag stack with the origin and target of the jump. You can navigate to older and newer tag stack entries using the new commands `pane::GoToOlderTag` and `pane::GoToNewerTag`. This is especially helpful for exploring codebases: it makes it easy to drill down into an unfamiliar function, then to quickly get back to where you were, without hammering the "back" button in the editor. While efforts have been made to make Vim users feel at home, there's nothing Vim-specific about the feature. Hopefully others find it helpful too!
b22e997 to
a44bebc
Compare
|
@cameron1024 alright, ready for another look! Test fix is in the first commit |
|
@cameron1024 is there anything I can do to help move this PR along? |
|
Apologies, got distracted with other things and haven't looked at this test. If you think you can take a look at it, go for it and ping me when you want another review :) |
|
I already fixed that test failure. Could you re-run the test suite? |
|
@cameron1024 looks like the tests passed. I'd appreciate it if you had another look! |
|
Looks great, thanks for implementing this 🙏 |
Happy New Years! This PR is a second take at #38127 (cc @ConradIrwin)
This PR is significantly less complicated than the last attempt: while we still keep our data on the
NavigationHistoryobject, we no longer tightly integrate it with the existing back/forward "browser history." Instead, we keep our own stack of(origin, target)pairs (in a struct to make it easy to extend with e.g., tag names in the future).The PR is split into two separable commits. Most of the implementation is in the second commit, which:
pane::GoToOlderTagandpane::GoToNewerTagin terms of the stacknavigate_to_hover_linksto push tag stack entriesThis last bit is the most fiddly. The core challenge is that we need to keep track of the
originlocation and calculate thetargetlocation across three codepaths that might involve creating a new editor and/or splitting the pane. One thing in particular I found difficult was that an editor'snav_history(anItemNavHistory) seems to be populated asynchronously. Instead of relying on it, I decided in this code to make my ownItemNavHistory. I briefly tried to refactor the code in question, but it seemed like it would significantly increase the scope of the change.I prefer this all-in-one tracking centered around
navigate_to_hover_linksto thestart/finishapproach taken in b69a2ea because I find it easier to convince myself that the right data is being populated at the right times. Of course, let me know if you think there's a better solution.Closes #14206
Release Notes: