(Following the pattern of reporting my most essential quick actions with the goal of being able to use vanilla VS one day. I think I messed up the order– this is my no. 1 priority.)
I'm estimating a minimum of fifty times a full workday that I used to use ReSharper's Alt+\ 'Go to file member' feature. It was great: I could press those keys and type part of the name and press enter without hesitating.
What VS gives is only Ctrl+T, which ReSharper also had, but with a toggle button tacked on which limits the search to the current document. The toggle button comes with two major problems which have frustrated me every time I've tried to start using it starting in March:
Rather than pressing Alt+\, I now have to press Ctrl+T, visually seek to the Current Document toggle button and identify whether it is on or off from my last unrelated use of Ctrl+T, decide whether corrective measure is necessary and potentially press Ctrl+Alt+C, then type part of the name and press enter. This is a distraction and comes as a visceral irritation.
How fast can you visually identify the Current Document toggle state in the following image? Keep in mind, prior to this, I didn't even need to look at what I was doing most of the time. This image is full-screen and my eyes start from the left middle of the screen, where my code is.
ReSharper's 'Go to file member' has an 'Include members from related files' checkbox (an additional Tab, Space if I want it). If a member is declared on a base type, this is the most intuitive and most efficient way to get to it.
It's nice to have this as an additional modifier always off by default because the need for it is rare most days, but there are times that my search had no results because I forgot that the member is on a base class and I'm glad that I don't have to start from scratch with a new keyboard shortcut.
I lean heavily on this when I want to end up in a library's decompiled source. Third party libraries often have complex inheritance hierarchies and I need to quickly jump up to a base type to see how it is implemented.
@sharwell can you direct this to Mark and Daofa?
@lineralpha
Good feedback @jnm2. Thanks very much.
We have a command to GoToMember (default shortcut Ctrl+1,Ctrl+M).
And we have a filter for "Current Document" (Ctrl+Alt+C).
But we have no command for activating GoToMember with the CurrentDocument filter on.
So, instead, you have to activate both commands separately (once you've established the state of the Current Document) - and then remember to turn off the Current Document filter when you're finished with it.
I don't believe we have any concept of "include related files".
Perhaps we should create a new command for "Edit.GoToFileMember" which will filter for members in the current file.
It should not change the user's "Current Document" setting for other searches/filters.
I suppose we'd also need to build an option for "Include related files".
This could be implemented as a separate GoTo filter button.
Just like the "File" or "Line" button, the Current Document filter would be disabled as it does not apply.
ie.
In the case of GoToFile, it makes no sense to limit to the current file.
In the case of GoToLine it makes no sense to allow anything outside the file.
In the case of GoToFileMember, it would only make sense to limit to the current file.
So in all these cases, the Current Document button would be disabled as the state is implied by the action.
Our default shortcut for this should be Alt+\, which is currently not bound to anything in the default mapping scheme.
@jnm2 Would you expect Alt+\ to also show types in the current document, or just members?
@sharwell I don't know offhand. My mental model (who knows if it's correct) is that nested types are members but I usually move even those to their own file. I can see how it makes the most intuitive sense to consider all names defined in the file to be 'file members' loosely speaking. I can check on ReSharper's behavior if you like.
A couple of times now today I've totally lost my mental stack just trying to get by without this feature. It could be frustrating if I let it.
If you look at this feature in isolation, it seems unfair to be irritated at something it does. But as I'm sure you know, IDE features like this are disproportionately likely to cause irritation because they are often used while your mind is already functioning near its stack limit so to speak.
One very cool thing I forgot about: if there are no matches and it matches members on a base class, it shows a message in place of the checkbox saying "No type members found in this file" and switches over to showing them. That explains why I very rarely even use the checkbox.
Good feedback. Thanks Joseph. Smart design makes a huge difference - especially when you're already holding a bunch of things in your head.
Joseph, this might help. I worked out a combination of shortcuts that can guarantee you can get members filtered by current document.
The trick is to use the "include contents from external items" filter (Alt+X) to disable the CurrentDocument filter.
Press:
Ctrl+1, Ctrl+M, then Alt+X, then Ctrl+Alt+C
When you press Alt+X, it always disables the CurrentDocument filter - regardless of the current state of the CurrentDocument or IncludeExternalContent filters. So you can press Alt+X once, then Ctrl+Alt+C to ensure your filters are set up correctly.
Sadly, this will leave your GoTo box in CurrentDocument filter mode, which will persist even when you close it and re-open it for a new Type, Symbol or Member search.
We're talking internally about producing an additional filter in the GoTo box for FileMember, which, like the GoToLine filter, will disable the CurrentDocument filter toggle because it will always be applied. And hence it will never affect the state of your CurrentDocument flag in the other filters.
Automatically switching to "include related files" when no results are returned is a stroke of genius.
We should look into implementing something like that.
In fact, that paradigm could be useful in other filters too (like IntelliSense).
I was redirected to this issue from here. My original issue is that 'Current Document' toggle does not actually limits the results within the current file.
Click Go To Member and type in some characters, the results may from any files in the solution even the Current Document toggle is on.
I've just tested GoToMember with CurrentDocument filter and found that it DID effectively filter on Current Document only.
@xtu - What version are you running?
@justcla I am using 15.5.4. I've recorded a video clip demonstrating the issue I'm having.
https://www.dropbox.com/s/prp4bhfwybg45kt/2018-01-26_17-16-33.mp4?dl=0
You can see the file I opened LayoutCable.cs
does have a member called GetLinkInfo
, but the search result list members from files even though they are not part of the solution.
Those look like C++ entries. Those are not handled by Roslyn.
Do you have any C#/VB results reported for items that are not from the current document?
I have a C++ project in the solution. You are right, those are from C++ header files.
I've tried several times in other C# files. It seems only entries from the current document and C++ header files are listed. I can't see any C# results reported for items that are not from the current document.
@Pilchie @jmarolf Can someone help file an internal bug that states that C++ is not listening to the 'in the current file only' filter? Thanks!
Sounds like the results from the C++ search results are not being filtered to the current document.
Filed an internal bug on the C++ team here
@justcla This is still my second most common reason for switching back to ReSharper. Any hope for this in 16.0?
(I apologize for the bump, I know you're all working hard!)
Absolutely! It's already been built. Check the latest preview of 15.8.
Enjoy!!! :-D
Note: Managed languages only. I don't know what's happening with C++.
Absolutely! It's already been built
I beg to disagree. The change is that the "current document" filter is on by default if you search for members. But I don't like that personally because I need to do both at times. Sometimes I know I want to search for a member in the whole solution, sometimes I want to only search in the current file.
I would really appreciate if there was a separate command/shortcut for Ctrl+T (for searching in the whole solution) and an alternative shortcut for searching in the current file (no matter where it's for a member or type, the experience would be the same as Ctrl+T but with "current document" selected).
@justcla Wow, nice! Thanks! 🎉
I'm also hoping for the ability to search in base classes of the classes in the current file. What are you thinking there?
At least it was my impression that this is what @jnm2 asked for as well. But maybe I'm wrong
Enjoy!!! :-D
I appreciate the efforts to improve things here but I personally don't see this as an improvement. It's not that I always want to search in the current file. I need to do both depending on what I'm trying to do, and I would be really helpful if there was a shortcut for each of these. Is this something that can be considered? Thanks
@Neme12 This issue is for 'Go to file member'. The thing that bothered me was that I used to have to keep in mind the state of the 'Current document' toggle, and that's no longer a concern. If I want to search members solution-wide, I use Ctrl+T.
Is the problem that Ctrl+T, m
automatically applies the current document filter? Huh, I could see that being weird. In practice I use Ctrl+T without the m
filter.
I use Ctrl+T too. But in 15.8, if I use Ctrl+T and then type m
, it only searches in the current file. This is not actually what I want at all. Up until now, I always used Ctrl+T + m
to search in the whole solution. I'm not saying that there aren't times I want to only search in the current file for members. I do but I wish there was a separate shortcut for that, so that I don't have to use Ctrl+T, type m
and then manually adjust the "current document" switch. If these are the steps I need to do, it will be better to keep using Ctrl+F as a workaround.
You can use Ctrl+Alt+C to toggle the Current Document filter.
Also, the GoToSymbol search might be good for a solution-wide search, as it contains all members, plus variables.
Just wondering, have you used a Solution-Wide GoToMember search anywhere else before?
You can use Ctrl+Alt+C to toggle the Current Document filter.
Thanks, I didn't know that. I'll try using that though that still seems like a complicated sequence of steps: Ctrl+T, Ctrl+Alt+C, m (and actually before pressing Ctrl+Alt+C, I will have to look whether it's already selected or not, so this won't work for muscle memory or as a quick shortcut at all because sometimes the filter will already be selected depending on what I did last time). My preference would be to have Ctrl+T and then Ctrl+(some other key) which is the equivalent of Ctrl+T but in the current file.
Just wondering, have you used a Solution-Wide GoToMember search anywhere else before?
I use this almost all the time. The majority of my Ctrl+T searches are for members in the whole solution.
Instead of Ctrl+T, m, you can use the new shortcut Alt+\.
Also, make sure you call up the Member filter BEFORE you toggle the current document filter, as typing "m" sets the Cur-Doc filter on.
You can reliably press Ctrl+T, m, Ctrl+Alt+C without looking if you want a global member search.
Or Alt+\, Ctrl+Alt+C
Also, the GoToSymbol search might be good for a solution-wide search, as it contains all members, plus variables.
I prefer to scope the search to exactly what I want, so for example if I know I'm looking for a member, I always type m
. I don't want to involve file search for example which is much slower, especially since I know I don't need it.
Also, there's a Ctrl+1, M shortcut for members.
What if we could have the Ctrl+1, M shortcut and the Ctrl+T, "m" do global search, but the Alt+\ shortcut would scope to current document and fly open the shortlist of all members in the current document?
Thanks but that's still the same number of steps, just in a different order. If I have to press Ctrl+T, then m
, then Ctrl+Alt+C, that's not very ideal :confused: especially since it's not consistently Ctrl+At+C as it depends on what I had selected the last time
What if we could have the Ctrl+1, M shortcut and the Ctrl+T, "m" do global search, but the Alt+\ shortcut would scope to current document and fly open the shortlist of all members in the current document?
Yes that is something I would very much prefer as it means that I have 2 easy shortcuts and I know exactly which one to use, without having to look at whether "current document" happened to be preselected.
When I said "global search", I implied setting current document filter to off.
I guess that would mean a change in behavior to NOT persist current document filter between search sessions. So then, each time you came into it, you'd know it was global.
Would that be an issue for people who always want to search the current document?
I'll suggest that to the team.
Thanks.
I guess that would mean a change in behavior to NOT persist current document filter between search sessions. So then, each time you came into it, you'd know it was global.
Actually that doesn't have to be the case. If there was an entirely separate feature to search for members in the curernt document (which I think is your suggestion), I could just use that any time that's what I need and only ever use Ctrl+T+m for the whole solution, which means I could rely on the current document filter always being off.
@justcla Yes! I like the sound of that.
So, base members?
My 2c. I hate the persisted nature of "search in current doc". Two reasons:
I'd much rather have distinct keybindings for searching, and i would not want things like 'current doc' to persist across searches unless i used that specific key-binding.
FWIW, base-members would be difficult for Roslyn to provide. It would require this feature to involve semantics, which would greatly slow it down. Right now the feature is 100% syntactic, and htat's very intentional for perf purposes.
Thanks Cyrus. Can you suggest that to Christian and Kasey?
My request for base members would be that they are only displayed if I tick a checkbox to include them, or if I have no other results.
@justcla I also have wished that 'Current document' was stateless from search to search. With Alt+\, it's still stateful even though the state is separate from the Ctrl+T state.
Also, when 'Current document' is toggled after Alt+\, it doesn't retrigger a search. Should I file a new issue here?
I don't own this area. But it sounds like it would be good to raise both issues you mentioned so that they can be considered by the team owners (and the community).
Tag @gundermanc and @kuhlenh
Most helpful comment
My 2c. I hate the persisted nature of "search in current doc". Two reasons:
I'd much rather have distinct keybindings for searching, and i would not want things like 'current doc' to persist across searches unless i used that specific key-binding.