Feature Reqeust: Also show line numbers in reference view

[abdulkareemnalband]

Also Show line numbers like
https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/v1_29.md#show-line-numbers-in-search

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Display line number as hybrid styles (#34715)
• Provide install number and update numbers separately (#60645)
• Interval line numbering show last line number and first selection line (#40431)

[pylgrym]

I feel this is crucial. I write and read a lot of code.
The line number is crucial in 'references' search results:
With VS-Code current search, it shows me 20 references for an identifier in a file.
But those 20 references occur in 3 clusters,
and to inspect/verify/identify a bug, I need to RECOGNISE those 3 clusters,
and read that each of them makes sense/has no bug.
When you refuse to show line numbers for your search results,
you force me to inspect each of those 20 instances manually, to figure out what those clusters are. Or rather, to use a different IDE that will show line numbers for search results.
Interestingly, in doing this you go against approximately 50 years (1970 to now) years of industry practice.
But I guess you know better.
UPDATE: Sorry, I meant 49 years, grep was not created until 1973.

[sushicw]

+1 to being baffled by this decision, not having the line numbers adds a ton of completely unnecessary friction when exploring code.

[nittdeniz]

Please consider reopening this. It is an absolutely crucial functionality and the information is already there, since you can jump to the position when you click on it. So it's just about adding an additional label to display the information beforehand.

[pylgrym]

I second this. In my daily work, I simply swap between VSCode and Visual Studio, because VSCode lacks this.

…

On Fri, 14 Apr 2023 at 09:46, nittdeniz ***@***.***> wrote: Please consider reopening this. It is an absolutely crucial functionality and the information is already there, since you can jump to the position when you click on it. So it's just about adding an additional label to display the information beforehand. — Reply to this email directly, view it on GitHub <#64521 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBASLNYUL2PHJKOC7B7F3XBD6GTANCNFSM4GI2AXTQ> . You are receiving this because you commented.Message ID: ***@***.***>

[LordRegentTB]

I am astounded that the ReferenceItem.asCopyText() method includes the line number references, yet there is an absolute refusal to surface that data in the typical UI where it will be most useful!

Seriously, try it: do Show All References (Shift + Alt + F12), context-click the tree, choose "Copy All", then paste into your favorite editor!

I patched up my nightly to show the location--since it is significantly eases the pain--and I'll keep doing so until somebody incorporates it (I am not yet comfortable with contributing to this project, or I likely would try myself.)

In the nightly, file resources/app/extensions/references-view/dist/extension.js is the target; around column 13070, replace:

,c={label:r+o+a,highlights:[[r.length,r.length+o.length]]}

with

,lp_LR=`${t.start.line + 1}, ${t.start.character + 1}: `,c={label:lp_LR+r+o+a,highlights:[[lp_LR.length+r.length,lp_LR.length+r.length+o.length]]}

then restart the program. This enhancement will unfortunately be lost on the next update, but this will demonstrate the feature and allow personal evaluation of whether it causes the text to overflow the panel too much for your own use. (If it does, play around with the preceding call to getPreviewChunks; give it two more parameters: 15 and !0).

This change corresponds (directly) to vscode/extensions/references-view/src/references/model.ts lines 290-293. Seems like a trivial thing to implement for real; my personal concern is that I probably have not followed the rules about "how" to build the string (am I supposed to use location from vscode.LocationLink, as it seems search-result does?), and I am not currently available to learn the approved method.

But, maybe I can get somebody else off the ground with this... Variable range is already set to the location, so make a const loca holding the formatted string (line 291, replacing whitespace), prefix loca onto the label field (line 293), and put loca.length as an addend to each of the two values in highlights (line 294); recreate the vertical whitespace after line 291, commit, etc, and submit a pull request.

		// ... @ line 290
		const { before, inside, after } = getPreviewChunks(doc, range);
		const loca = `${range.start.line + 1}, ${range.start.character + 1}: `;

		const label: vscode.TreeItemLabel = {
			label: loca + before + inside + after,
			highlights: [[loca.length + before.length, loca.length + before.length + inside.length]]
		};

		const result = new vscode.TreeItem(label);
		// ...

[matthewkooshad]

i'm surprised this feature is not there for references like it is the search results on the UI.

[stamminator]

@jrieken Please see @LordRegentTB's comment. It looks like a trivial change, and it would eliminate a needless pain point. Respectfully, I don't see how the out of scope label makes any sense for this issue, seeing that ReferenceItem.asCopyText() already exposes this information and other code editors, including Visual Studio, don't have this gap.

[jgaardsted]

It is really annoying. As it is, I switch to visual studio when I have to do refactors of this kind.

I question the wisdom of deliberately hiding relevant context,
in the act of trying to show me the relevant usages.

When I do a search like this, my use case and intention is "Please show me WHERE THIS IS USED".
If you don't want to show me the line numbers, you are not showing me WHERE :-/.

This is connected to a related misguided design intention for this feature:
In the aim to 'dumb down' and 'minimalize' the presented view, it also filters out horisontal context from the search results!
That is, if the matching line contains whitespace after the matched function call,
the stuff after the whitespace is hidden too!
THIS DOES NOT MAKE SENSE!
If you remove all SURROUNDING CONTEXT, what your terminal result becomes, is this (below here):
That is, you can dumb-down the displayed result so much, that showing it becomes meaningless.

(To work around it, I (for VSCode's sake - sigh!) now write my code like this:
model.MatchedFunctionName(project)//no-spacing-in-my-context-comment-because-if-I-put-spaces-after-(-this-context-is-not-shown-sigh)

model.MatchedFunctionName(project)
model.MatchedFunctionName(project)
model.MatchedFunctionName(project)
..
model.MatchedFunctionName(project)
model.MatchedFunctionName(project)
model.MatchedFunctionName(project)

[carlgieringer]

Please reopen or at least provide an explanation of why this feature will not be implemented. "Out of scope" of what? Isn't the scope of VS Code to be a useful code editor? Is there a reason that this feature would not be useful? If it would be useful, is there an argument that it is too costly to maintain relative to its benefit? An answer to these questions would help the open source community understand this decision not to support this requested feature, thank you.

[Novack]

Closing such a small and basic element -requested with plain and self evident arguments-, without any rationale. This is how fake open source works. This is how MS deals with issues on its software now: "we accept pull requests" and "out of scope" aka "do your own extension".

[pylgrym]

To be fair, it leaves one usecase open for their flagship product Visual Studio, which I must switch to, whenever I need to do this.. :-) :-(

…

On Tue, 23 Apr 2024 at 01:13, Novack ***@***.***> wrote: Closing such a small and basic element -requested with plain and self evident arguments-, without any rationale. This is how fake open source works. This is how MS deals with software now: "we accept pull requests" and "out of scope" aka "do your own extension". — Reply to this email directly, view it on GitHub <#64521 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABVBASND4NTECBMEVXOLRB3Y6WKTNAVCNFSM4GI2AXT2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBXGEYTANBRGQZQ> . You are receiving this because you commented.Message ID: ***@***.***>

[bevin-hansson]

Can this be reopened? It doesn't make any sense that this feature is out of scope. The Search view even has it.

[dwillis77]

Thank you @LordRegentTB for the tip on the workaround! Works great (although now it appears to be around column 19597 in the current version of resources/app/extensions/references-view/dist/extension.js).

@jrieken , please reopen this issue. This is a critical functionality as many others have mentioned - I'm surprised this didn't come up during initial implementation of the "find all references" feature. Seeing a huge list of references without line numbers reduces the usefulness of the feature a lot. Sure I can click each result to jump to it to see where it is but with the line numbers present, I have a general idea of where each one is, which means I can probably find the reference I'm looking for in one or two clicks instead of having to go down the entire list to check every single one. The more references a symbol has, the more valuable the line number feature would be.

Combine that with the fact of how simple it seemingly is to implement (see @LordRegentTB post) and this should be a no-brainer. It should cost minimal time to implement but would provide great value to many users in return. Seems like an easy win to me.

As a side note/related request, the same functionality in the "peek all references" pane would be great to have as well.