Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Namespace Nesting in the Tree View #2666

Closed
ds5678 opened this issue Apr 6, 2022 · 3 comments
Closed

[Feature Request] Namespace Nesting in the Tree View #2666

ds5678 opened this issue Apr 6, 2022 · 3 comments
Labels
Enhancement Areas for improvement

Comments

@ds5678
Copy link
Contributor

ds5678 commented Apr 6, 2022

Currently, ILSpy always flattens namespaces in the tree view like this:

{} Top.Middle
{} Top.Middle.Bottom1
{} Top.Middle.Bottom2.EvenLower
{} Top.Middle.Bottom3

It would be more intuitive and less cluttering if there was an option to organize it like this:

{} Top.Middle
    {} Bottom1
    {} Bottom2.EvenLower
    {} Bottom3

Where Bottom1, Bottom2.EvenLower, and Bottom3 are child nodes that can be collapsed into Top.Middle.

@ds5678 ds5678 added the Enhancement Areas for improvement label Apr 6, 2022
@siegfriedpammer
Copy link
Member

As the namespaces in metadata are just strings, how exactly would you separate "Top.Middle" from "Buttom2.EvenLower"? What are the rules?

A simple rule would be: new level after every dot, and would look like this:

{} Top
    {} Middle
        {} Bottom1
        {} Bottom2
            {} EvenLower
        {} Bottom3

But that is not exactly what you want, right?

@ds5678
Copy link
Contributor Author

ds5678 commented Apr 6, 2022

I chose my example like that because it's more vertically and horizontally concise. The idea was that an inner namespace section could be absorbed into an outer namespace section if it's the only thing the outer section contains. This is common for libraries with prefixes, for example: ICSharpCode.SharpZipLib.

Dividing by dots might be better because it's simpler, and therefore it's probably easier to implement and faster at runtime.

@ds5678
Copy link
Contributor Author

ds5678 commented Apr 7, 2022

Thank you

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Enhancement Areas for improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants