Open vsopko opened 7 months ago
It depends:
Local methods inside methods tree (and appropriate chekcbox in filter area)?
I am not convinced that local methods are the subject of navigation within the document. They live in a method, they make sense only within that method. If you cannot navigate within the method and need to use extension as CodeMap then most likely your method is too large and needs refactoring, after which your local methods will most likely become type methods.
User defined background colors for tree nodes quik navigation (some kind of bookmarks)?
It's a bit challenging to find an adequate UX for that. Tracking renamed code tree elements is not trivial, persistence is another big question. The idea of this extension is to be a lightweight alternative to big tools like CodeMaid. Thus it is deliberately slimmer than they. But I will give it some thought.
Filter for structs visibility?
Yep, this can be done. Changing the issue to the enhancement.
It's a bit challenging to find an adequate UX for that. Tracking renamed code tree elements is not trivial, persistence is another big question.
I suspect that user data is stored in a *.suo file. Regarding UX: I think minimalism and simplicity is good. Right-click on a node, choose a color from the standard palette and this is enough without any additional editors.
*.suo file
The choice of file is not a problem. It can be all inside of .vs folder and hidden away from the user. However, the file will need to contain the information for all files ever opened in this VS solution. Hm.... But , well, doable.
Tracking the bookmarks is a more serious challenge. If user renames the method name (e.g. Method_A
-> Method_b
), which is marked with the color, how do you know that Method_B
node needs to be coloured? It's impossible without replicating IDE own edit tracking mechanism. Which is an overkill if you ask me. Giving up on changes tracking can be an option though.
Selecting the colour from the menu is OK. Agree.
Giving up on changes tracking can be an option though.
I think it's enough to just point in the documentation "If the user renames type - the colored bookmark will be deleted" and not reinvent the spaceship. Even built-in bookmarks sometimes get lost or goes to the wrong lines over many years and studio versions. And it can be assumed that even Microsoft has unsolvable problems with tracking of code changes.
... just point in the documentation "If the user renames type...
yep, that is exactly what I had in mind as "giving up"
Done. Update the extension to v2.2.0.0
Done. Update the extension to v2.2.0.0
Great and fast implementation! Thank you!
If I may, here is some suggestions to make the user interface cleaner:
Left side - current version, right side - with proposed changes
I actually tried to do exactly that. But my WPF became rusty over the years and I found myself being really slowed down so decided to release something rather functional and resume chasing these improvements next time I revisit the extension.
Please look at this extension https://marketplace.visualstudio.com/items?itemName=SamirBoulema.CodeNav2022 Its functionality is okay for me, but performance and UI is terrible. Is it possible to implement from there: