Wiki Link: [discussion:520]
Future Focus: Searching and Navigating to Symbols 

Coordinator
Jul 11 2008 at 1:28 AM

Please enter your feedback on the symbol search feature here.

Jul 11 2008 at 10:09 AM
It would be best if the search is at least to some respect language-aware, and uses the knowledge of the language to decipher queries. For example, I would expect to be able to type "struct Foo" in a C# project, and get result list restricted only to classes; but in a VB project, it would be "Structure Foo". Similarly, in a C# project, I want to be able to type ":Control" and get a list of all classes that inherit from Control; for VB, it'd probably be "Inherits Control". And so on, for all distinguishable kinds of types, for function overrides and shadowing declarations ("override ToString"), for "Implements" and "Handles" in VB etc. Though some common syntax for use in multi-language solutions may still be handy.

On a side note, if you go that way, it may be good to be consistent with naming of articles on classes/methods/... in MSDN Library index, which is in reverse order - you type "Control class" and "ReadLine method". Since many people use index as a primary way to navigate MSDN, they are necessarily familiar with this naming scheme, and it could be easily extended as needed.

Jul 11 2008 at 11:35 AM
I would say definitely non-modal. If I'm searching I often find myself needing too look at the context around the result before I can tell whether it is the right one or not. If it's model it's very difficult to do this.

Jul 11 2008 at 4:15 PM
Edited Jul 11 2008 at 4:32 PM
Off the top of my head, making symbol search overly complex will give it usability and acceptability issues. It needs to be easier and quicker to use than Find in Files and have at least the same functionality as the existing Symbol Search (Look in references, Whole word, Prefix, Substring, Match case, navigate to next result, navigate to previous result, and filter by: My Solution, .NET Framework, All Components, Custom Component Set)

An option for regular expressions (.NET regular expressions) seems like a good idea.

More importantly, writing code is largely a keyboard intensive exercise; if symbol search can't entirely be used with keyboard shortcuts it's not something I (and many others) would find useful.

What I would define as minimum functionality:
  • symbol search is a float-able/dockable/tab-able/auto-hide-able window.
  • symbol search window can be opened/given-focus via keyboard shortcut.
  • ability to jump to the next symbol that matches the search term.
  • ability to jump to the previous symbol that matches the search.
  • ability to jump to the next symbol that matches the search term via keyboard shortcut.
  • ability to jump to the previous symbol that matches the search via keyboard shortcut.
  • ability to list real-time results in symbol search results window.
  • the symbol search results window should be a "Results" window that utilizes F8/Shift-F8 for goto next location an goto previous location, respectively.
  • the symbol search results window should be a float-able/dockable/tab-able/auto-hide-able window.
  • an open symbol search window synchronizes with code changes (e.g. if the window is open and I remove a symbol from my source code the symbol search will reflect that in a reasonable amount of time).
  • look in references.
  • whole word.
  • srefix (or regular expression).
  • substring (or regular expression).
  • Match case.
  • filter by My Solution.
  • filter by .NET Framework.
  • filter by All Components.
  • filter by Custom Component set.
  • automatable through macros.

lower-priority features
  • ability to list one-time results in Find Results windows.
  • ability to use .NET regular expressions in search terms.

I don't think it's necessarily vital that we be able to filter on members, variables and type names; but it seems logical.


Jul 11 2008 at 4:33 PM
Good ideas!

I would love a way to implement diagrams, images, and color-coding features in the source code as well with some ways to add comments (like a Word comment.) Then be able to search for all of that in a “Google-like manner” (sorry for that reference!)

Coding should be as much of a story as it is X’s and O’s. Help us to tell a better story!

Jul 11 2008 at 6:56 PM
0) Either non-modal, or lightweight borderless tooltip-like window. Have a MRU list for previous searches.

1) A little preview right off the result list is desirable. Whenever user navigates through results up/down, preview window updates and shows the relevant portion of code for a selected match.

2) Language awareness and context awareness is vitally important. Instead of sophisticated search syntax/settings go for intelligent rating/ordering of match results. Full-word match goes before partial-word match, case-sensitive match goes before case-insensitive. Search matches within the current project go before matches from external libraries.

3) Allow searching in dependencies (including binary DLLs) and known system libraries (even not added). Put those results below source code matching in rating.

4) Search for GUIDs, WM_XXX messages and other known constants. So if user enters '10023100', it should give 'SQLDMO Database Role' API as a first result. For 783 it should give 'WM_QUERYNEWPALETTE'.

5) Allow full-text searching to appear in the list. Put those match results below all other matches.

The key is to create a big lookup index for all the development-relevant stuff and intelligently tune it to the current context (opened file(s), project type, IDE package). That would make it a one big killer feature.

Features that require extensive search (like full-text one) might be started after a 1/2 sec timeout, and only if the existing match list doesn't contain high-relevant matches. If there is an instant match, no need for a full-text search, but it's great to have it as a fallback when nothing else matches.

Jul 11 2008 at 7:00 PM
By the way, if you do create a lookup for system constants, GUIDs and APIs it might be good idea to make it available for Windows Vista shell search as well. This way developer could click 'Start' button and type in 'WM_SHOWWINDOW' and get the link to the API documentation without getting through opening the IDE.

Jul 11 2008 at 7:05 PM
And use icons for different types of matches: properties, fields, classes etc.

Jul 11 2008 at 11:28 PM
I've always wanted to limit the scope of a search to a) only comments, b) only active code, or c) only string literals. One of my pet peeves is searching for a commonly-used word and then wading through tons of commented-out code to find the active code. While you're at it, maybe you could also add a way to restrict the search so that it doesn't search the auto-generated code (I know: hidden text checkbox -- but I like to "hide" most of the code I write, so that checkbox stays checked).

Jul 12 2008 at 8:11 AM
Of all the things in Visual Studio that need improvement, this isn't even on the radar. The Object Browser has reasonably good search capabilities already, and any new features should be built on top of it.

I think a lot of this perceived need would go away if C# adopted VB's shortcuts. In VB pressing F-12 takes you to the code, if available, or the Object Browser entry. In C# you get that stupid code skeleton, even if the code is in the same solution. This makes browsing far more difficult than it needs to be.

Jul 12 2008 at 9:20 AM
I like the way Resharper has implemented similar functionality i.e. the "Go To" family of commands.

http://www.jetbrains.com/resharper/features/navigation_search.html

Jul 14 2008 at 7:49 PM


I think a lot of this perceived need would go away if C# adopted VB's shortcuts. In VB pressing F-12 takes you to the code, if available, or the Object Browser entry. In C# you get that stupid code skeleton, even if the code is in the same solution. This makes browsing far more difficult than it needs to be.

I have no problem in Visual C# pressing F12 and it going to code in my solution rather than the metadata.

Jul 15 2008 at 1:37 PM
Must have from my point of view: knowledge of camel case conventions.
If I have a type named CodedInputStream for example, I should be able to enter CIS in the search, or CodIS, or CInSt etc.

This is a huge time saver in other environments which already have it (Resharper and Eclipse for example.)

Jul 15 2008 at 5:46 PM
Edited Jul 15 2008 at 5:52 PM


jskeet wrote:
Must have from my point of view: knowledge of camel case conventions.
If I have a type named CodedInputStream for example, I should be able to enter CIS in the search, or CodIS, or CInSt etc.

This is a huge time saver in other environments which already have it (Resharper and Eclipse for example.)

I agree; but I have the feeling that Camel Case really isn't in the purview of this "new" feature. Frankly; the way it's proposed--as a fewer-features adjunct to the existing Symbol Search--begs the question "Why"?

A new-and-improved Symbol Search; yes, please. But, another Symbol Search with fewer features: there's more important work to be done.

It would be really easy to implement Camel Case search, like C[a-z_0-9]*I[a-z_0-9]*S[a-z_0-9]*, Cod[a-z_0-9]*I[a-z_0-9]*S[a-z_0-9]*, C[a-z_0-9]*In[a-z_0-9]*St[a-z_0-9]* with RegEx..

EDIT: changed regular expression examples so they're not marked-up.

Jul 15 2008 at 9:59 PM
I have to agree that the need for this feature is questionable. Effort toward the next version of Visual Studio should be put toward improving performance (Visual Studio is known as the slowest IDE in the programming industry), and the many bug fixes and features which the community has been requesting, some of them for years. Just scroll through the Visual Studio feedback at Connect and you will see so many ideas that would be much more useful than this.

Maybe as a part of these future focus articles, Microsoft could provide some kind of justification for why they feel the feature is important enough to crowd out other community-requested features?

Jul 22 2008 at 12:25 AM
Edited Jul 22 2008 at 12:27 AM
Just copy the features from IntelliJ. They already did this, and did it RIGHT. Eclicpse is a distant 2nd, but OK if you don't have the $.

Every day I miss these features from IntelliJ. Then I remember I had to use Java to get them, and it doesn't hurt so bad ;)

I think is is long overdue. In response to some other commenters:
  • Case doesn't matter. All searches should be case insensitive, regardless of where they are.
  • Camel Case search is NOT very useful, but wouldn't be terrible. At the point when I can really use it, I already know what I'm looking for and don't need the search.
    • Those that are talking about camel care are using it for Intellisense, basically, not for unknown-member search.
    • Unless you plan on using this for navigation, above search, then it's not so useful.
  • MRU lists I wouldn't really use. Unless I have no memory, and the dialog is too slow, then I would need them.
  • PLEASE don't return constants when I enter 783, and so on. Infinite performance drag. Infinite nitpicking, too.
  • Type & Method search MUST be different search windows, or different invoke shortcuts. I already have a tool that puts them both in one. I spend more time toggling options/etc than actually searching because of this, so I don't use it any more. Please don't do this!
  • Basically anything that Mihalik says, ignore. The best tools out there do not do those things, for a reason.

And copy a few other related features (type serach/navigate to file/recent files/search) while you are at it. After $xxx for VS & upgrades, I shouldn't be needing to buy hundreds of dollars in ADDONS to get this, and other, basic editing tools for non-trivial code bases.

I've been waiting 5 years for you to copy their most basic features, but you still aren't there yet. And now this! You have a working, kick ass example out there already. I know this is just the VB team, but seriously... How old is this issue? I think VS is the only IDE out there that doesn't support this in some fashion (not including scripting-lang IDEs, though even some of THOSE do!)

by the way, finally something with wiki syntax =) thanks

Jul 22 2008 at 12:32 AM

PeterRitchie wrote:
Off the top of my head, making symbol search overly complex will give it usability and acceptability issues. It needs to be easier and quicker to use than Find in Files and have at least the same functionality as the existing Symbol Search (Look in references, Whole word, Prefix, Substring, Match case, navigate to next result, navigate to previous result, and filter by: My Solution, .NET Framework, All Components, Custom Component Set)

True, it needs to be faster. That is really the only requirement, though. If it is fast enough, it doesn't matter what you are searching =)

In response to some points farther down, go check out DevEx's search dialog. It has all these, and more, features. The problem is, it is a mess to use because of them. I'll take the simple, quick, list that is filtered by what I am "using/importing" in my file over that any day. If I have to expand it to areas/dlls that I haven't imported or referenced directly, make that a simple check box.

Please guys, do this simple, quick, and right. You really don't need much to solve 95% of the issues, and some of these requests sound like "please, I don't want to read documentation! read my mind, find it for me!" and "my code is a mess, so when I search for 7, return everything with 7 in the name, the value, 7 lines, 7 character names, or that sounds like the word "seven".

Jul 22 2008 at 1:11 AM
Keep history of searches - or better allow several windows open, I definitely have multiple tracks going and will need to repeat searches. I frequently use the search results 2 of Find In FIles and wish there were about four available. So, building this non-modal and allowing multiple would be lovely.

Yes, use columns and let me sort on any column. Let me pick from possible columns and rearrange as well as sort. Among the list include visibility, proximity, applicability score, source type, file name, project name, class Name, member name etc. Maybe also how many times I've used it. I'll get the hang of which I care most about. This is a first cut at solving the filtering problem, although to be really slick, you'd give a combo box in each column header which included everything in that column and let me pick from what was displayed.

You are correct to think keyboard experience!

Not modal! Either work like an Intellisense popup (and that's getting pretty crowded) or a normal dockable VS window. I dock the other search.

Don't waste a lot of time on preview - one line preview as a tool tip may be adequate (the issue with teh current preview in Find In Files/Find Symbol is that you scroll too much, columns would fix this.

Include an option to search all loaded libraries (ex. .NET framework)

Current search is pretty good if you include go to def, go to type def options, find symbol, find in files. I definitely spend a lot of time pouring over FindInFiles so it could be better. But this is not a feature I would have put at the top of the hit parade.

It does give us ONE MORE way to land in a generated file. PLEASE add management of generated files including background coloration and possibly locking. Locking is problematic and the wash probably sufficient.

Jul 22 2008 at 1:46 AM


KathleenDollard wrote:
It does give us ONE MORE way to land in a generated file. PLEASE add management of generated files including background coloration and possibly locking. Locking is problematic and the wash probably sufficient.

That's an excellent point. An option to ignore generated code would be very handy.

Jul 22 2008 at 3:57 AM
Options are evil. Any single one checkbox in that dialog would lower its value by $100. Put ten of them there and you'll have to give money back for VS Professional.

Make it as simple and intelligent like Google web search, or Google code search. Or even simpler.


You could pre-index all the system libraries and constants. This will give .NET Framework and Windows SDK search matches back in milliseconds. Search through real sources can be incrementally indexed too. Consider index size, consider system caches, be smart, don't build 1000 plugins multitier architecture.

The idea is to make it faster than human. People cannot type without Intellisense anymore. Make them addicted to search-navigation same way. Currently I can recall path to most classes faster than IDE searches. Beat that. Those IntelliJ and Eclipse with all their bazillions of sophisticated gimmicks will look stupid and overcomplicated if you get the search right.

Jul 22 2008 at 10:53 AM
Edited Jul 22 2008 at 11:01 AM
EditPad Pro has an excellent search (and replace) UI.
One nice feature is its wide-multiline search box which allows for lengthy search strings.

The multiline search box also allows searching for multiline matches with-or-without regular expressions.

The editor also highlights search matches in code.

My last request is to replace the Visual Studio proprietary regular expression syntax with industry standard regular expression syntax, e.g. to search for any whitespace, use "\s*" instead of ":b*"

http://www.editpadpro.com

Jul 22 2008 at 1:38 PM


devJohn wrote:
EditPad Pro has an excellent search (and replace) UI.
One nice feature is its wide-multiline search box which allows for lengthy search strings.

The multiline search box also allows searching for multiline matches with-or-without regular expressions.

The editor also highlights search matches in code.

My last request is to replace the Visual Studio proprietary regular expression syntax with industry standard regular expression syntax, e.g. to search for any whitespace, use "\s*" instead of ":b*"

http://www.editpadpro.com

The proposal is about a new symbol search. Symbols cannot contain whitespace, so multiline support isn't related.

Aug 2 2008 at 3:20 AM
Wow all these really advanced features and there are really just basic features that need really to be looked at:

When searching for files and I say ".vb" the "" really means ALL. Everything that has a file name that ends with .vb that Includes Page.Aspx.VB as well as UserControl.ASCX.VB or MyClass.MyChildClass.Vb. for some reason the IDE really misses out on that, Its annoying to have to search and entire solution for ".vb;.aspx.vb;*.ascx.vb; etc..." to find all the .VB files

When I hit cancel it means CANCEL... not hang my computer up for 20 minutes forcing me to whip out the task manager and kill the process to cancel a search. This is particularly true when search Web Apps. Also why the need to download every file when searching a Remote Web Application... I mean all of the files are currently in the cache.. There should be some kind of idle background file syncronization going. Try searching a web app with large pdf's of other NON .Net related files. Good Luck!!. I need to have my html open the site in dream weaver.

Aug 6 2008 at 6:00 PM
If I'm searching for a symbol, I want some context about it in the results. If I enter a class name, I want to know what results are part of the class definition, what are instantiations, what are instances, what are subsclasses, and what are references to static members. Similarly, with a variable name, I'd most want to know if it's used as an rvalue or an lvalue in the resulting location. Both of these require either some language awareness or a much more detailed symbol browser than we have now.

Otherwise, it isn't necessarily better than "Find in Files" over the solution (which currently gives me some context).

Aug 18 2008 at 9:52 PM
I wish that if the search, when it opens an outline to show hidden text, would close that outline again if I did nothing other than search again.
Also I really want a find prevous button.

Aug 18 2008 at 9:59 PM
I use outlining to visualize and navigate my code, but outlining conflicts with my prefered method of searching which is incremental search (ctrl i). Incremental search skips hidden text, making it uselss.

Aug 28 2008 at 3:42 PM
This feature sounds great, if it will perform and not re-compile the solution like refactoring does now.
My wish list:
- lightweight (ReSharper style - one line, expand result set)
- allow wildchards search (.:?) (foo*bla)
- I type "foo" tell me everything that is "foo*" in current solution ordered by distance from current point in code
- If I type "foo*.bar"
- If there is nothing, expand automatically to "foo" in current solution
- If there is nothing expand to imported types
- 100% keyboard navigatable: Shortcut + foo + down,down + Enter
- be instant


Updating...
Page view tracker