Yanking to a given line number is not respected in find-in-project results

[AaronFeickert]

Check for existing issues

• Completed

Describe the bug / provide steps to reproduce it

When yanking (in Vim normal mode) to a given line number while viewing a find-in-project search result containing multiple results, individual files' line numberings are not respected.

Here's an example test file:

Suppose I perform a find-in-project search for test:

Next, I navigate the cursor to line 6 (Quux) in Vim normal mode and enter y8G.

I would expect three lines to be yanked: lines 6, 7, and 8. Instead, Zed reaches across both results, yanking lines 6 through 15.

It appears that Zed is not interpreting the range 8G with respect to the original file (and the line numbers that appear in the search results), but instead is interpreting the range with respect to a different numbering for the entire result buffer. That is, it counts lines 6 through 10 as the "first" five lines, and lines 13 through 15 as the "remaining" three lines in the 8G range.

Environment

Zed: v0.164.2 (Zed)
OS: macOS 15.1.1
Memory: 18 GiB
Architecture: aarch64

If applicable, add mockups / screenshots to help explain present your vision of the feature

No response

If applicable, attach your Zed.log file to this issue.

Zed.log

[ConradIrwin]

Your interpretation of what's happening is correct. In this case you expected it to yank out of the original buffer instead?

I'm not sure what the "right" thing to do is; internally Zed thinks of a multibuffer as just one big file, but it is confusing to have the line-numbers from the original files when using something like this.

[AaronFeickert]

@ConradIrwin: Right, I would expect the lines from the original buffer to be used, especially since the original buffer's line numbers are used in the multibuffer.

I think the Right Thing would be always to use an original buffer's data, but acknowledge that this seems likely to break the "multibuffers are still buffers" architecture you indicate. After some head scratching, I can't think of a use case where'd you want the "secret internal" multibuffer line numbering to be used instead.

[ConradIrwin]

I think relative line numbers could still make sense, but it looks like they're not implemented in a useful way in multi buffers either 🤦 .