Feature Request: Scope Guidelines about codist HOT 30 CLOSED

Hi,
Thanks for sharing your idea.

Got it.
I had not yet found out how this feature could help coding.
I will try to figure out what is the usefulness of this feature.

from codist.

I am developing a new feature in Codist, which will be release in the upcoming version 4.0.

I don't want that line to distract me while I am reading the code. So the line similar to the implementation of Viasfora will not be a feature in Codist.

Instead, that new feature will let you do more. You can see the boundaries of statements and expressions more intuitively and those boundaries will only show up on demand, when you hover the mouse over somewhere, a new element, in the document window. So they won't be a distraction.

from codist.

I'd just release a new version (see the Release section in this repository). A new feature called Navigation Bar will help you to see the spans of those blocks (see ReadMe page). Please give it a try and share your thoughts.

from codist.

Thank you very much for your detailed feedback and encouragement.

1. I had not remembered that regions were treated as document trivia by Roslyn. I will try to exclude it in the next build.
2. I have also noticed that the drop-down box in the original navigation bar also lists members from other code files for partial types. I will see whether it is possible to find out those members and include it into the drop-down menu.
3. It is reasonable to include the regions, although I seldom use them. I will see how to obtain the list of them in a code file.
4. Yes, I remember your request of rearranging declaration blocks. However I am so new to WPF and it may take me quite some scores of hours...

from codist.

I knew what you were talking about.

I'd like to address the partial support first, since the original navigation bar has that feature. And the next will be an advanced filter for the NaviBar menu items.
The collapsing #region will be of low priority.

BTW, do you have some code examples about drag-and-drop-enabled WPF menu items?

from codist.

I am sorry that I found the guild lines distracting to me after working with them for sometime.

Lines were flashing around my eyes as I clicked around the code.
Of course, the colors of the lines could be adjusted.

The major problem is that I could not find them helpful, since the indentations of code lines had already implied the scope of the block where the caret was in. I could not remember that there was any moment that I got lost and needed those guidelines during my coding. Furthermore, I did not yearn for it after disabling that feature.

Thus I will leave this feature request here at this moment until its helpfulness is witnessed. You'd better stick with Viasfora.

I'd love to work on other features that you can't see in other extensions which help programmers understand or navigate through code files better.

from codist.

Thank you for sharing your thoughts! I certainly understand your reasoning, and agree with you completely that it would be better to work on features that do not exist in other extensions first.

For my part, I do find these guidelines helpful, because for instance, sometimes the code may be formatted in such a way where indentation is not reflecting properly the structure of the code, or has been collapsed into a single line.

But thank you for considering this feature at least.

from codist.

Thank you very much for your kind comment.

sometimes the code may be formatted in such a way where indentation is not reflecting properly the structure of the code

I did encounter such kind of code files, written by someone else. I usually use the Format Document command in VS to reformat the document.

has been collapsed into a single line

Bingo, you jogged my memory!
The guideline can be helpful when a single line contains a lot of enclosed statements.
I did have similar idea like that before.
Maybe there would be a similar feature in the future. But please be patient, very patient :).

from codist.

Sounds very interesting! Can't wait to give it a try!

On a somewhat related note, maybe you can consider adding statement / block terminator adorners (i.e. icons and/or text after the closing brace), so that it is clear which block has just ended. Perhaps it may be even possible to only make those visible if the start of the block is not (to lessen possible distraction). These icons could then have additional functionality when clicked - maybe a small menu would appear asking you if you want to collapse the block, or, if it's a member, move the member implementation above/below other members, etc.

from codist.

Just installed it... It looks awesome! What a great feature! Congratulations on your hard work! I just hope that the performance will not be affected as much (all the other similar extensions I tried are really slowing VS down).

I am just surprised that Microsoft have not updated this area in nearly 20 years - it essentially looked and functioned the same way as in the VB6 days!

I really like that by default all members / types are shown in the order that they appear in the document.

A few small suggestions / issues (I will add more as I encounter them):

• Sometimes when you click on a member, the selection is a bit too large:
  

I guess it has to do with extra comments / regions

• It would be nice to also incorporate "partials" support (maybe via toggle). The default way in the VS is that all members that are part of the type but are not defined in the same file are also displayed in the navbar dropdown, albeit greyed-out. So, it would be nice to see those as well (maybe via optional toggle (hidden by default). An even better possibility would be to also include file name where they are defined (to the right of the member name).

• It would be great if somehow regions could be incorporated as well. If the whole member/type is enclosed in a region (usually with additional types/members) then on your drop-down list you display those items grouped - perhaps with a clickable header - that will identify the region where the affected items are located. This feature would be active on at least 2 levels: the namespace level (since more than one type can be defined in the same namespace, in the same region, in the same files), and the type level (since obviously within the same file there can be regions, each with several members).

• Finally it would be super awesome if you could also enable drag/drop (or maybe a simpler version) to re-arrange members/regions/types within a file. This is just an idea, haven't thought of specifics yet.

Overall, great work, as always!

from codist.

Just installed latest version from the Gallery - 4.0.1.2663.

Thank you for so quickly introducing Regions support to the NavBar! Noticed the first bug:

Basically Region's start and end tags (items in the list) are swapped.

Also, I know you mentioned you are only starting out with WPF, but perhaps in the future, you could implement regions as collapsible tree nodes, or alternatively as their own level(s) in the NavBar (depending on where they appear - between namespace and type for regions containing entire types, and between type and member for regions containing members only within the same type).

from codist.

Thank you for reporting this bug. I made some tweaks on the display of #regions. Please try the new release.

from codist.

The #region and other directives lay above the hierarchical syntax tree structure. Thus, strictly speaking, it is inappropriate to enclose tree nodes into regions. Thus I might make clicking on a region to select its content for further editing in the future, but not enclose members into it.

from codist.

I see. Yeah, I guess it can be a bit tricky. I suppose you should aim for the most practical approach that makes sense, i.e. regions can be containers for types or members, and thus UI should somehow be able to reflect it, that's really all I was implying.

from codist.

Codist.zip

This one has added partial type support. Please try and see whether it works on your projects.

from codist.

Thank you for the updated version. Your prioritization makes sense! I will try it out and let you know if ther are any issues.

As for WPF drag-drop, I am new to WPF myself, so can't be of much help here. But as far as I remmeber CodeNav offers drag-drop support, so perhaps you can see how they have implemented that. (I am not using their extension because it's way too slow and unstable).

from codist.

Just gave it a try. The UI for the partial types looks very good, like how you organized it. However, it crashed VS the very instant I tried to move the mouse over one of the members defined in another file (the type was a partial static class, if it is of any relevance). Here's the error log:

Application: devenv.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException
   at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetSymbolInfoFromNode(Microsoft.CodeAnalysis.SyntaxNode, System.Threading.CancellationToken)
   at Microsoft.CodeAnalysis.CSharp.CSharpSemanticModel.GetSymbolInfoCore(Microsoft.CodeAnalysis.SyntaxNode, System.Threading.CancellationToken)
   at Codist.SemanticContext.GetSymbol(Microsoft.CodeAnalysis.SyntaxNode, System.Threading.CancellationToken)
   at Codist.NaviBar.CSharpBar+NaviItem.NaviItem_ToolTipOpening(System.Object, System.Windows.Controls.ToolTipEventArgs)
   at System.Windows.Controls.ToolTipEventArgs.InvokeEventHandler(System.Delegate, System.Object)
   at System.Windows.RoutedEventArgs.InvokeHandler(System.Delegate, System.Object)
   at System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object, System.Windows.RoutedEventArgs)
   at System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean)
   at System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs)
   at System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs)
   at System.Windows.Controls.PopupControlService.RaiseToolTipOpeningEvent()
   at System.Windows.Controls.PopupControlService.OnRaiseToolTipOpeningEvent(System.Object, System.EventArgs)
   at System.Windows.Threading.DispatcherTimer.FireTick(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.DispatcherOperation.InvokeImpl()
   at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object)
   at MS.Internal.CulturePreservingExecutionContext.CallbackWrapper(System.Object)
   at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
   at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
   at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object)
   at System.Windows.Threading.DispatcherOperation.Invoke()
   at System.Windows.Threading.Dispatcher.ProcessQueue()
   at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef)
   at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate)
   at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32)
   at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)

from codist.

Thank you very much for finding this bug.
I could reproduce it on my computer too. It had not crashed my VS and I overlooked it during the test.
While the tooltip for the menu item was to popup, Codist would lookup the semantic model for symbol information. The semantic model was the active document but the node was actually in another one, thus it crashed your VS.

Please try this new beta.

Codist.zip

from codist.

Oh I see. Thanks so much for the quick fix! Will test it, and let you know if I encounter any other issues.

from codist.

A couple of things:

1. There is an issue with display of "region" items:

displayed for this:

As you can see, the EndsWith2 is not part of any region (this was just a test on my part). Yet, on the NavBar it is displayed as part of STARTS-WITH/ENDS-WITH region.

2. In 1 above I added the EndsWith2 routine to another file (partial static class) just as a test. I waited ~10 seconds for VS to "compile" everything in the background. Then I switched back to the document that did not contain EndsWith2 that I just added, but did contain other members of the partial static class. Unfortunately, NavBar did not reflect the newly added member until I closed and reopened the document.

from codist.

Problem 1, as well as the collapsible region problem, will be left there for some time until I find some way to denote the scope of the region.

Problem 2, thank you for reporting this. The semantic model, used by the Navigation Bar in the first document, was not updated since that document was unchanged, even though the referenced one had been changed. Currently, you need to edit the first document to force the semantic model to be updated.

from codist.

I see, thank you for the explanation.

1. For the mean time, you could just return to your initial version of <> and </> for region start and end designators respectively, so that clicking on <> will navigate to the start of the region, while clicking on </> will navigate to the end of the region. Right now, I think you essentially chose not to display the end region item at all, and that's why, I guess, EndsWith2 in my example above appeared as if it was part of the previous region. So, if you, for the time being (while you think for the better alternative), could just add back the display of the region's end as well, that would be great.

2. So, in the future release you plan to make it so that it would be updated automatically?

from codist.

Problem 1 appears to be solved without great effort. Please try this new beta. I used a separator to denote the end of a region. If nothing is between #region and #endregion, the #endregion will be simply hidden.

Problem 2 is a headache. This beta will update the semantic model when you click elsewhere in the document and expand the menu of a partial type, which could help fix the problem to some degree.

Codist.zip

from codist.

Thank you for such a quick update! You work around the clock!

For me at least, it definitely is better with some kind of end region designator as opposed to none! So, thank you for providing a fix! Stylewise, however (and this is just an opinion of course), I would prefer the "section" title to not be centered, and instead be left-aligned. Since it is already bolded, and has a unique icon, making it centered achieves no additional separation - it is already pretty clear that this is a title of a section (partial type in a file and/or region).

Also, I seem to have liked the previous region icon better. Perhaps an icon with +/- or # would be more appropriate. But of course it's a very minor thing and really a matter of taste, so don;t take it too seriously!

from codist.

Just a quick suggestion... Perhaps you can find a way to display useful statistics in the NavBar (either directly on the headers/titles, or in the tooltips, or some other way) as to the number and kinds of members in a type / region and number of types in a namespace.

from codist.

Which one looks better?

It seems that the last one is the best, in which the item enclosing the primary caret is painted with a different background, and the region items are bold, standing out of other members, and they are left aligned, symmetrical with the endregion items.

from codist.

As for the "useful statistics", I am sorry that I never think that I need to know the number and kinds of members in a type / region and number of types in a namespace. I previously, more than one time, had an idea that displaying the line number count somewhere in the editor window, quite similar as displaying the number of members--it is a piece of cake. However, I refrained from doing so, as we program logically. The relationship among types and members are much more important than the number of types or members. Knowing a type contains X members or Y members does not help a programmer to write code in better logic.

from codist.

I generally agree! However when you are developing a sizable library or a framework, it can be useful to know this info, especially when you are trying to figure out how best to balance out static utility classes for example. Perhaps you can just add it to a back log - a low priority thing for the future?

from codist.

UNDERSTOOD. It is piece of cake and the major difficulty is to find somewhere appropriate to place those numbers.

But, it is a little bit off topic in this issue.
Could you please open a new issue for this idea?

I am going to close this issue and let's make subsequent discussion about the Navigation Bar or other things on new issues.

from codist.

I am sorry I seem to have missed your question on the style... Yes, I agree with you, to me the last variant looks best! Also, it's easier on the eyes, because all the items are left-aligned, so you don't have to scan across.

Will submit new issue for the statistics, as you suggested.

from codist.