Suggestion: Favorite files, functions, types

[Decimation]

Problem

By default, Visual Studio has bookmarks which bookmark line numbers in files. However, these bookmarks are limited in their bookkeeping/organizational ability:

• If the value of the bookmarked line number changes, then the bookmark loses its purpose
• If the file changes, bookmarks are lost or disorganized

Solution: Favorites

Favorites would function similar to bookmarks but would keep track of the specified favorite in a more organized fashion. For example, the user could favorite the following items:

• Functions
• Types
• Files
• ...

[wmjordan]

@fitdev Any comment on this? How about the long requested Tab Groups (#80)?

[fitdev]

I think Favorites feature would be nice, and I do agree that the existing Bookmarks feature of VS is rather limited, since it is text-based only and lacks semantic understanding, which would needed to "bookmark" a type or a function. I do not at the moment see how it can be easily combined with my Tab Groups feature suggestion, since these two seem to be different features, although they can certainly interoperate.

Personally I am more in need of tab groups and saving multiple Solution Explorer views than Favorites, but this feature is certainly nice to have.

Perhaps this Favorites feature can be made into advanced Object Browser / Class View feature, since the VS's built-in Class View is very limited. The way I see it, ideally it would be a combination of Object Browser and Class View with Favorites, where Favorites would simply reference items from the combined Object Browser / Class View.

Implementing this "Type View" if I may call this should be easy since you likely already have most of the code in the NaviBar, it's just a matter of slightly different presentation - in a tool window, instead of as part of the document or in floating windows, and using TreeView instead of a List.

This tool window can then have 2 tabs: the main Type View and Favorites.

Some ideas about Favorites in particular:

• You can add items to Favorites from various places: the Type View, the NaviBar, SuperQuickInfos.
• You should also then be able to organize those Favorite items into arbitrary folder hierarchies of your choice.
• Or at least be able to assign them to various user folders (perhaps just 1 level deep). This would be especially useful when working with either multiple or large solutions or several features. So that for feature A you can have a Favorites A folder, and for feature B you can have Favorites B folder and so on.
• Some favorites can be marked as per-solution, and some can be global (i.e. when they reference System/Framework items). Although this is an advanced scenario and perhaps is not as important.
• Clicking on the item in either the Type View or the Favorites would by default navigate to definition.
• Hovering over an item should display a nice SuperQuickInfo as it would in code.

Lastly, to tie it with Tab Groups feature in the future, perhaps there can be the ability to open all items from a particular Favorites folder in a new tab group (similar to how you can open multiple bookmarks in Firefox web browser for example).

[wmjordan]

Good to hear that.

Unfortunately, several days ago our country has abruptly loosen the counter-COVID measures. We've been so well protected for these 3 years, most of the time free to go everywhere in our mainland without a mask, and now we are suddenly on our own. I am not very sure about my own health and in a panic of learning and preparing for the upcoming virus wave.

[Decimation]

@fitdev:

Perhaps this Favorites feature can be made into advanced Object Browser / Class View feature, since the VS's built-in Class View is very limited. The way I see it, ideally it would be a combination of Object Browser and Class View with Favorites, where Favorites would simply reference items from the combined Object Browser / Class View.

Implementing this "Type View" if I may call this should be easy since you likely already have most of the code in the NaviBar, it's just a matter of slightly different presentation - in a tool window, instead of as part of the document or in floating windows, and using TreeView instead of a List.

This tool window can then have 2 tabs: the main Type View and Favorites.

I agree, this is similar to what I had in mind.

Some ideas about Favorites in particular:

• You can add items to Favorites from various places: the Type View, the NaviBar, SuperQuickInfos.
• You should also then be able to organize those Favorite items into arbitrary folder hierarchies of your choice.
• Or at least be able to assign them to various user folders (perhaps just 1 level deep). This would be especially useful when working with either multiple or large solutions or several features. So that for feature A you can have a Favorites A folder, and for feature B you can have Favorites B folder and so on.
• Some favorites can be marked as per-solution, and some can be global (i.e. when they reference System/Framework items). Although this is an advanced scenario and perhaps is not as important.
• Clicking on the item in either the Type View or the Favorites would by default navigate to definition.
• Hovering over an item should display a nice SuperQuickInfo as it would in code.

Lastly, to tie it with Tab Groups feature in the future, perhaps there can be the ability to open all items from a particular Favorites folder in a new tab group (similar to how you can open multiple bookmarks in Firefox web browser for example).

I also agree with these suggestions.

@wmjordan that's unfortunate; I pray for your safety. Thank you again for your great work on this extension and supporting it.

[fitdev]

@wmjordan Please stay safe! Hopefully this will be over soon. And once again thank you for all your efforts with this amazing extension! I hope you will continue to add great new features in the future!

[wmjordan]

Thank you for your blessing, my friends.

Just two questions off-topic: Have you ever suffered from the COVID-19? If not yet, how do you and your family survive from it?

[fitdev]

Have you ever suffered from the COVID-19?

I think I have had it twice. Both times it was like a mild flu - fever for a few days, and then I recovered over the next week. I think you should be ok. From what I read, it is usually only the elderly people or people with some lung or other conditions who are at a high risk. Still, best to be safe and use all the precautionary measures - masks, etc. Hope all will be well!

[wmjordan]

@fitdev Thank you for sharing.

The death ratio of COVID-19 in our country is still very low at this moment, since the virus has not yet fully spread. About 300 thousands of people were infected this year and few died according to official reports. Since we are not so old, we'd better keep our body safe and avoid infection for the future decades in our life and our family.

[O-n-y]

What do you think about Class explorer, i requests? I think it should fit the needs! https://github.com/wmjordan/Codist/issues/235

• you could favorite item from that view - so it will be up at the list and maybe have some decoration - like to be bold the star icon would appear when you hover over item in that list - so you can click it - after this action, item would be in favorite.

[wmjordan]

In previous commits, I solved some problems with namespaces, which inspired me something about this request.

The most challenging part is to relocate the symbols after source changes. For code files, types, fields, properties, events, things are easy.

For methods, since there can be quite a few overloads for them, we have to make an efficient way to identify them. Or we don't try to identify each individual overload, but address a method with its name only. When it is clicked, a menu displaying all possible overloads appear and we can choose one from them, or an overloaded method can be expanded.

[fitdev]

Yes, I think your suggestion for methods is how it should work to avoid unnecessary complications. Because not only can there be different overloads, but method signatures may change too. So I think, it would be enough to identify a methopd by its name, containing type, and possibly a return type.

[Decimation]

In previous commits, I solved some problems with namespaces, which inspired me something about this request.

The most challenging part is to relocate the symbols after source changes. For code files, types, fields, properties, events, things are easy.

@wmjordan Are you talking about symbols as in pdb files? If so, have you tried using symchk or symstore? Also the dbghelp Windows API provides functions for interacting with symbol files. Additionally, check this tool out: dotnet-symbol. Further reference about .NET symbols here.

[wmjordan]

Are you talking about symbols as in pdb files?

No. I was talking about the ISymbol related stuff in Roslyn.

[wmjordan]

it would be enough to identify a methopd by its name, containing type, and possibly a return type

Thank you for sharing your thoughts, @fitdev . The return type of a method is seldom used to identify the method. The name, arity and containing type are usually sufficient to address the method, if overloads are not concerned.

[wmjordan]

Darn, the economy is getting bad. I have got to pay more time to the management of the company where I am working, otherwise it can bankrupt.

Time for Codist in the upcoming year will be scarce.

[fitdev]

Hopefully things will improve next year economy-wise!

Perhaps then only language-related features and serious bug fixes/crashes should then be prioritized?

[wmjordan]

Yes, bug fixes/crashes will be always be addressed.

[wmjordan]

I need a tree view control to present the favorite elements. @Decimation @fitdev @O-n-y or someone else can recommend a WPF tree view control?

Ideally, we should have a multi-column tree view, with drag & drop support

[fitdev]

I don't know much about WPF unfortunately. Perhaps you can take a look at the one used by ILSpy, though it is not a multi-column one, but perhaps it can be a good start, with multi-column support planned for the future.

[Decimation]

All I know of is TreeView but it's not multi-column. There are custom controls which you may be able to use.

[wmjordan]

Hmm, maybe multi-column is not a must. But drag-and-drop should be the feature your want.

[Decimation]

Hmm, maybe multi-column is not a must. But drag-and-drop should be the feature your want.

If you want multi-column, you could use ListView. If you want a tree view, you could use TreeView. All of these controls support drag-and-drop; in fact most WPF controls support drag-and-drop.

[Decimation]

@wmjordan in regards to your problem with uniquely identifying symbols:

The most challenging part is to relocate the symbols after source changes. For code files, types, fields, properties, events, things are easy.

For methods, since there can be quite a few overloads for them, we have to make an efficient way to identify them.

...

The return type of a method is seldom used to identify the method. The name, arity and containing type are usually sufficient to address the method, if overloads are not concerned.

Most structures in the .NET CLR have a unique metadata token. See this MSDN article, for example. All MemberInfo subtypes have a MetadataToken property; e.g., FieldInfo. You could use this metadata token for unique identification and tracking.

[wmjordan]

@Decimation Thank you for replying. Codist don't use reflection. It uses Roslyn to parse source code and imported assemblies to gain information about code symbols. Hereby MetadataToken won't help. Fortunately I recently remembered a way to identify and retrieve symbols and it won't take too long to implement. Now the hardest part is the user interface.

[wmjordan]

Theoretically this function is implemented. However, I have not yet made an interface for it, which requires much more time. I will release version 7.9 first and work on it later.