make finding all references more user-friendly

[ramya-rao-a]

From @bruceauyeung on March 7, 2017 8:45

Finding all references will popup a window to show all references, i think it's a little hard to use, i am not blaming vscode-go, maybe it's vscode's limitation because vscode don't provide a view similar with output, problem etc.

1. once user close the popped-up window, referencing results is lost. user have to find all references again if they just closed the window by accident. most other IDEs such as Eclipse, Gogland, they display references in a view , the referencing results will not be lost until user do finding all references again.
2. user may close the window by accident very easily. currently the window have a close button, a window bar, if user single-click the left part of menu bar or drag the window on left part of menu bar( mouse pointer becomes to a finger when hovering on it, this indicates user can do something ), window will be closed.

so i suggest:

1, if it's possible, display references in a view similar with problem etc, not in a popup window. if not,
2, do not close window when left part of menu bar is clicked or dragged, only close window when close button is close or content part of window is double-clicked.

Copied from original issue: microsoft/vscode-go#845

[ramya-rao-a]

@Microsoft/vscode thoughts?

[aozgaa]

One suggestion: populate a left-side tab/button (along the lines of Explorer, Search, etc.) with the search results and then allow clicking/wheeling/scrolling through the results. This probably shouldn't re-use the current Search view as one might want to retain both lists of results.

[mejamiewilson]

I'm a big fan of using the panel part for this (where Output / Problems etc live). Rift view is great for things that are relevant to the piece of code you're looking at as it keeps context of where you launched it (peek definition works perfectly), but for something that touches / references multiple files the way the References view does, it makes sense for it to be docked and therefore visible across files.

Adding a 'References' tab to the bottom panel, and rendering the references rift view in it would be 90% of the work needing to be done. Knowing how to keep the context of the original token clicked / code referenced would be the UX concern needing most work.

This ticket doesn't have much interest, I'd be interested to know if people simply prefer the rift view than one of these suggestions?

[jayars]

+1 from me.

Am in the middle of refactoring a typescript project, and it's getting just a tad painful.

Wishing the results of Find All References can be pinned or made persistent, until manually cleared.

Personally, I think it would fit very well into the Search pane.

[jrieken]

fyi - I once did a sample extension of a virtual document provider which shows results of reference search in a separate (persisted) editor: https://marketplace.visualstudio.com/items?itemName=jrieken.references-plusplus

[masaeedu]

Pretty please with sugar on top? It is basically impossible to navigate large codebases when the only tool at my disposal is the Alt+Left history stack. Even a simple feature like "open in new tab" for the find all references view would be a great improvement. Right now I have to get pen and paper to keep things straight.

[stevencl]

Thanks for the feedback. There are a few things we should do:

1. Don't close the peek window when clicking on title bar elements. We should only close when the user presses the close button or presses the Esc key.
2. Add a button that allows the current set of references to be persisted in a read only document, similar to the extension that @jrieken referenced above.
3. Implement cascading peek to avoid losing the set of references when following another set from within the peek window:

[nicksnyder]

The proposed changes would be an improvement, but I want to offer two opinions:

1. I dislike peekview because it is a scroll view in a scroll view. This is a poor user experience (especially on small screens) for a couple reasons:
   • Awkward scrolling on original file
   • Not enough context on file with references. In other words, I frequently end up scrolling around inside of the peekview.
2. I dislike peekview specifically for find references because I would rather be able to quickly switch between full files (like search does) then split my screen/attention by embedding some results in the existing file. If I find a reference file that is interesting, I want to pin it in a tab side by side, not keep it in a peek view. If find references behaved more like search (results docked somewhere) it would already open as a (probably unpinned) tab, and side by side would just be a hotkey away.

I understand that some people probably like peek view and it is useful in some circumstances, but it would be nice for there to be a viable (configurable) alternative.

[andy-block]

I am also not a fan of the peekview. I found it super confusing when I started using VS code. In fact, I think it was the main thing that caused me to discard VS Code when I first tried it; I only gave it another shot after encouragement from a colleague, and have since grown to love it on the whole :). But I haven't grown to love peekview over time.

My preference would be:

a) for it to be configurable whether find references would use the peek view or a regular search results window.
b) (really nice to have) for multiple search result sets to be supported, along with the ability to pin sets such that they won't get overwritten by new searches.
c) (ideally, but not essential) to have a button on peek views that would allow that to be converted to regular search results.

I think being able to treat "find references" as a regular search would be much more user friendly - you are essentially searching for places in the code, after all, just using different search criteria. Why should the visuals & navigation differ between the two?

[7sempra]

+1 to putting the results in the standard "search" sidebar. We've already got a place for "list of search results pointing to sections in files". Also would avoid losing vertical space to a problems tray.

That said, I would also take the problems tray approach. As long as the view persisted and got out of the main editing area, I would be happy.

[pepve]

Whenever I try to use Find References now, it just adds to my confusion. The file within a file view (peekview? rift?) just doesn't work for me. I would have expected the results to show up in the left pane or the bottom pane. I'd like to suggest a configuration option that changes this behavior.

[elpixo]

+ Separate window (preferably in landscape view at the bottom; like Terminal, Problems, Output etc)

[mbenkmann]

I think the implementation of "search.location": "panel" (issue #45063 ) and the new Search panel that comes with it would be a perfect opportunity to implement this feature request. If Find All References results went to the new Search panel that would be perfect.

[jrieken]

Merging discussion from #44414 (comment) into this issue. For the March release we are adding F4/Shift+F4 to navigate across results in reference search. On top, this should work after closing the peek view widget (or moving the peek view widget into the bottom panel).

[andy-block]

Merging discussion from #44414 (comment) into this issue. For the March release we are adding F4/Shift+F4 to navigate across results in reference search. On top, this should work after closing the peek view widget (or moving the peek view widget into the bottom panel).

@jrieken I was real excited to see 1.22 (March release) appear in order to try this out - but I just tried it out there, and while F4/Shift-F4 seems to work while the peek view is open, it doesn't seem to work after closing it. I'm also not clear if/how you can move the peek view widget into the bottom panel (is that already possible? I'd like to try that if so).

I get the impression from #44414 that these changes got pushed back a release ("Closing this as we have F4/Shift-F4 in latest insiders. The continuation, esp. navigating references without peek view, is now tracked in #22261"). Any idea on a new ETA? Thanks in advance,

Andy

[jan-zajic]

+1 putting ref results in persistent panel like in any other productive IDE. Current implementation is totaly useless (unless you searching for one concrete ref, which is, in my point of view, minor usecase). Current impl forcing to use of search for anything else (for example refactoring).

[syclee]

Any updates on this? Plenty of design feedback in this thread. No reason to hold off on scheduling this into a future milestone?

[jools-adams]

I have to say I've stuck with the peek window for references and tried to find benefit in it and get used to it. for over 18 months. For me at least it's still really cumbersome.

+1 for simply putting the found references in a panel, or just like the search results are done. Being able to pin the results, and have new sets of references in a new panel / search results areas would be a bonus :)

(Sorry about the gripe, VS Code is fantastic in general).

[object88]

Going to chime in here as well; peek view is not optimal for most of my Find All References needs. The peek does not always provide enough context, and if I navigate to a reference, the peek view closes. Further, if I need to do this in multiple locations, I need to perform the Find a second time. I would love to see an option to fix the results to a search results panel, which would even be updated if the references change.

[shawndotey]

+1 for putting the found references in a panel

[uglycoyote]

I also detest the peek view window, like many users here. I thought I would add my two cents because there are couple things that I don't know if they have been said:

• The peek window works very poorly on narrow monitors. It's not that I have a particularly low res screen, but I always code on a vertically oriented monitor to get more vertical real estate, but the peek view seems to have been designed under the assumption that you have lots of width. This screen is 1920x1200, so I have 1200 pixels of width. With the scroll preview on the right and the file explorer on the left, I'm left with at best 600px for the peek view since it opens between those two. Then it splits that in half, so I really only get about 48 characters wide little window into the code, which makes me feel claustrophobic.
• The fact that it is rendered right inline is not helpful to me, and is visually confusing to have a snippet of code from somewhere else displayed right in the middle of where I am. There's not enough of a visual separation between the "code here" and the "code somewhere else". They seem to be all jumbled up.

I would be happy with either the solution that Sublime employs (search results in another tab), or the one from regular VS/Resharper (search results in a dockable at bottom).

Or even, as other people suggested, it would be fine to have the search results displayed in the left docked bar as the regular ctrl-shift-f search results do. Though again that solution has the horizontal real estate problem for me, I like to keep my left-docked bar skinny and find that every time i do a search I need to drag it wider and then narrow it again when I am done. So, displaying search results in a new buffer or in a bottom-docked window would be ideal.

[haugerbr]

@uglycoyote not sure which search you are talking about but if you add "search.location": "panel" to your settings you'll get search in the same place as terminal instead of the left bar.

[uglycoyote]

@haugerbr that's good to know, thanks! I tried all kinds of tricks to mouse-drag the search results down to the bottom. Having to configure this in json settings is not very discoverable, but I'm glad it's there. Now, if only there were an equivalent "findusages.location":"panel" setting, then it seems like many people on this list would be happy.

[haugerbr]

@uglycoyote it's also discoverable right clicking on the search panel although it says Toggle Search View Position so it's not really clear what it does. But I agree, find usages/references could act exactly the same way.

[frevds]

@stevencl @jrieken Any update on this? Please add a setting as "findusages.location": "panel" to allow alternative display of reference results in the panel (same as with search results).

The major problem is that the overlay closes when one merely wanted to open the code location for better editing (double-clicking the code or switching the tab and gone are the results, which is very annoying). It is rather difficult to position the overlay in a way that enough code is visible for editing, and nested scrolling adds no benefits either. Also it is not easily distinguished visually from the code below the overlay. A splitted tab layout would be better here.

[stevencl]

Sorry for the radio silence and lack of updates. We are now starting to get around to discussing this and it's on our UX backlog of work.

Unfortunately I have no concrete updates at the moment though.

[frevds]

No problem, enjoy the UX planning.
I just wanted to let you know the community is still very interested in this feature. Your work will be greatly appreciated ;].

[jrieken]

For the upcoming October release we will bundle a references view extension with VS Code (https:/Microsoft/vscode-reference-view).

This is available and installed by default in latest insiders: https://code.visualstudio.com/insiders/. Please give it a try. #HappyCoding!

[frevds]

That sounds great!

I went to install the extension V0.0.6 into my regular VSC, instead of using the separate Insider edition.
It however does not seem to work for me.. it does show the right files containing references, but there are no sub nodes with actual results, just empty root nodes for the file:

No errors to be found in the console.

[jrieken]

I went to install the extension V0.0.6 into my regular VSC,

Yeah, you MUST use latest insiders for this because it uses some API that came in hot 🔥

[uglycoyote]

@jrieken that's really exciting that something is finally happening with this, and we may finally be freed from having to view these results in the wretched peek window. However I do have a couple of concerns about the solution that is being implemented:

• It's confusing now that there's going to be two different context menu options for this, from the looks of your screenshots, we now have "Find all References" and "List all References". I assume both of these are supposed to find the same collection of results and just display them in a different format. Both the old and the new context menus are "finding" stuff, and both are displaying the results in a "list" of sorts. So, the language used here in these context menu options seems unhelpful in disambiguating between the two options.
• Wouldn't it be better to make this a setting? I propose that a better UI would be a setting called "Display 'Find References' Results as..." with choices that are something like ["Sidebar", "Inline, in Peek Window"] or whatever terminology makes sense and clearly distinguishes between the two different methods that the results can be shown as. My preference would be to never, ever, see the peek window again in my lifetime, and would rather not have a context menu option that i might accidentally open the peek window with.
• It seems odd and perhaps bad that this is being implemented as an "extension". Other features such as "Find in Files" display their results in a sidebar. Are those implemented as "extensions" as well? Why shouldn't the "Find References and display in sidebar" be just a native part of the core application functionality? Maybe this is partly related to my first concern, as I assume that the reason why this is a second context menu option is because it is an extension, i.e, extensions probably don't have the ability to change the functionality of existing context menu options, only to add new context menu options. What other aspects of the functionality are crippled by this being an "extension"? How can we be confident that both options will give the same results if one is "native" and the other is an "extension"?

[avkonst]

In addition to the above. As a user of vscode, I expect my find references hot key combination to open the side bar list. It seems list references is not bound to the same hot key combination.

…

On Sun, 4 Nov 2018, 11:14 uglycoyote ***@***.*** wrote: @jrieken <https:/jrieken> that's really exciting that something is finally happening with this, and we may finally be freed from having to view these results in the wretched peek window. However I do have a couple of concerns about the solution that is being implemented: - It's confusing now that there's going to be two different context menu options for this, from the looks of your screenshots, we now have "Find all References" and "List all References". I assume both of these are supposed to find the same collection of results and just display them in a different format. Both the old and the new context menus are "finding" stuff, and both are displaying the results in a "list" of sorts. So, the language used here in these context menu options seems unhelpful in disambiguating between the two options. - Wouldn't it be better to make this a setting? I propose that a better UI would be a setting called "Display 'Find References' Results as..." with choices that are something like ["Sidebar", "Inline, in Peek Window"] or whatever terminology makes sense and clearly distinguishes between the two different methods that the results can be shown as. My preference would be to never, ever, see the peek window again in my lifetime, and would rather not have a context menu option that i might accidentally open the peek window with. - It seems odd and perhaps bad that this is being implemented as an "extension". Other features such as "Find in Files" display their results in a sidebar. Are those implemented as "extensions" as well? Why shouldn't the "Find References and display in sidebar" be just a native part of the core application functionality? Maybe this is partly related to my first concern, as I assume that the reason why this is a second context menu option is *because* it is an extension, i.e, extensions probably don't have the ability to change the functionality of existing context menu options, only to add new context menu options. What other aspects of the functionality are crippled by this being an "extension"? How can we be confident that both options will give the same results if one is "native" and the other is an "extension"? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#22261 (comment)>, or mute the thread <https:/notifications/unsubscribe-auth/ADyZVcXi4sls5MCbwgCJ44Y_n8y2ww8Xks5urhUsgaJpZM4MXfMf> .

[jrieken]

assume both of these are supposed to find the same collection of results and just display them in a different format.

Sure, this is to complement this existing peek UI and not to replace it. We generally do not take something away from users. You might disagree but many users actually like the peek UI and taking that away isn't an option. We have issues to add a setting to disable peek view (#53164) and we track user defined (context) menus, see #9285. Already, today you can configure (and overwrite) the keybinding to be whatever you like best.

Wouldn't it be better to make this a setting? I propose that a better UI would be a setting called "Display 'Find References' Results as..."

Disagree - it shouldn't be either-or but use what ever is best for you, e.g. users might use peek for a quick glance to understand how some piece of code is being used while the references view is a more stable list that can be used as a todo list.

How can we be confident that both options will give the same results if one is "native" and the other is an "extension"?

It is always another extension that provides the data, VS Code just presents that data. Having this as an extension is a good thing because it means we validate and improve the extension API for something we ship. That means the API will improve and that means every extension will benefit from this.

[jrieken]

Closing this now as we have a first version in insiders (http://code.visualstudio.com/insiders/). Further issues should be raised here: https:/Microsoft/vscode-references-view/issues