Codist 6.6 Beta

[wmjordan]

Download

Codist 7690

Codist 7670
Codist 7668
Codist 7664
Codist 7655
Codist 7634
Codist 7622
Codist 7617
Codist 7608
Codist 7572
Codist 7556
Codist 7550
Codist 7525
Codist 7507
Codist 7456
Codist 7450
Codist 7434

What's new

• General
  • Fixed some functionalities were not working in some content types (b7456)
  • Displayed method parameter names, default values and generic type argument names in C# Symbol Tool Tip (7655)
• Resource Monitor
  • Added CPU, disk and memory monitors (7690)
    
• Super Quick Info
  • Changed the alternative style for C# Quick Info to concise symbol signature (Suggestion: Another representation of Super Quick Info #216, Suggestion: Option to show generic constraints in multiple lines #211, 7608, 7617, 7622, 7634, 7655, 7664, 7668, 7670)
    
    
  • Displayed type arguments for generic type (7608)
  • Many enhancements and bug fixes for C# Quick Info (7655)
• Syntax Highlight
  • Highlighter could starve thread pool in some cases (Codist causing Visual Studio responsiveness issues #215, b7450, 7550, 7556, 7572)
  • Highlight customization in other textual windows were supported (Suggestion: Set output line colors by rules #184, b7456, 7507, 7525)
  • Memory leak in C# syntax highlighter (b7507, 7525, 7550)
• Smart Bar
  • Images on Smart Bar were blurry if editor window was scaled (Smart Bar上的图标模糊 #213, b7434)
  • Used proper way to determine multi-line selection (b7450)
  • Added more commands to C# Smart Bar (7507)
  • Changed tool tip styles (7608)
• Navigation Bar
  • Changed tool tip styles (7608)

[wmjordan]

Hi @fitdev

I found that some features of Codist were not working in the newly introduced markdown editor from VS 17.4 preview 2. Beta 7456 should have this fixed. Please help download and test the beta.

During my local test, something weird occurred.
I compiled a 7452 version and installed the VSIX file. Afterward, the installation of Codist got completely broken. It even vanished from the Installed Extensions window. I recompiled it several times with VS 2017 and VS 2022 and eventually this 7456 got installed.

If the above weirdness happens to you, please let me know.

[fitdev]

Thank you for letting me know about this. I have not yet installed the latest VS Preview. Will do so next week probably. However I am not a good choice for testing markdown features since I do not use markdown in VS at all, and don't even know what features Codist has in regards to markdown. I only use Codist with C#. But I will certainly let you know if I encounter any issues with the latest beta.

[fitdev]

BTW It would be really great if you could implement a more detailed list of interfaces in the Super Quick Info tooltips, where it shows the whole interface inheritance chain for each interface. I am now working on types with like 30+ interfaces with complex hierarchies and generic parameters and it would help a lot to know exactly through which higher level interface a lower level interface like IEnumerable<T> for example has been inherited.

Here's an example screenshot:

[wmjordan]

Well, understood. You situations are really complicated.
For instance, the declared interfaces are A, B, C.
A inherits D, E, F.
B inherits D, G, H.
C inherits E, I.
F inherits H, J.
I inherits K.
J inherits K.

What do you think is the best way to show the above interfaces? Should those interfaces duplicated by inheritance be displayed multiple times?

Anyway, I will release a version 6.5.1 to address the issue #215 first and see whether the problem is resolved.

[fitdev]

Ideally I think there should be two possible views between which you can switch. Or maybe a unified view but with an option to turn a list-like view into a more detailed tree-like view.

• The simpler, list-like view is basically the way it is now but with an additional piece of information: show (inherited through InterfaceName(s)) instead of just (inherited). So, in your example, F would show that it is inherited through A; D would show that it is inherited through A and B; E would show that it is inherited through A and C; G - through B; H - through B; and so on.

• The second view should be a tree-like thing. It can be done in 2 different ways (both have their pluses and minuses):

1. A tree according to inheritance level, where the level of inheritance is represented by spacing on the left:

A
  D
  E
  F
    H
    J
      K
B
  D <-- Note: duplicated
  G
  H
C
  E <-- Note: duplicated
  I
    K <-- Note: duplicated

2. Alternatively, existing list can be made into a 2-level tree, where for each interface, there will be child node(s) that describe inheritance chains:

A
B
C
D
  Inherited through: A
  Inherited through: B
E
  Inherited through: A
  Inherited through: C
F
  Inherited through: A
G
  Inherited through: B
H
  Inherited through: B
I
  Inherited through: C
J
  Inherited through: A - F
K
  Inherited through: C - I
  Inherited through: A - F - J

(I hope I have not made a mistake, but you get the idea). I think - can be used as a separator, or perhaps some kind of arrow/icon to indicate inheritance direction more clearly. Also I think it is better to start the child nodes with the declared (parent-most) interface and work our way down towards the target interface, and not the other way around, so that you immediately know where the interface is coming from.

I think probably the 2. variant is a better one, because the tree's depth is only 2 and it has less duplication and it basically builds upon the current list, so will likely be easier to implement.

Regarding responsiveness: At this moment I have not encountered any issues. But as I have explained, I do not multi-target, and very rarely edit files in shared projects, which is likely why I have not been affected.

[wmjordan]

Thank you for your comment. I think variant 2 is identical to the "simpler, list like view" actually.
I will check to see whether it is possible to implement that in the next version.

[fitdev]

I think variant 2 is identical to the "simpler, list like view" actually.

I don't think so, because the current list does not duplicate items, whereas my proposal does (when some interface is inherited through more than one path).

After thinking a bit more about this, I think that my variant 2 of the tree-like list would be the best. However I would add 2 more optimizations to it:

• When there is just on inheritance chain, there is no need to make the interface's node into a full tree-node, i.e. the inheritance chain can be shown in-line (as the same item) with the interface.
• When Generics are involved, it would be great if interfaces that differ only by type parameters are grouped. To illustrate this I have added A : X<A>, B : X<B>, J : X<J> to your example, with the expected presentation given below:

A
B
C
D
  Inherited through: A
  Inherited through: B
E
  Inherited through: A
  Inherited through: C
F (Inherited through: A) <-- Simplified to just one line/item because there is only a single chain
G (Inherited through: B) <-- Simplified to just one line/item because there is only a single chain
H (Inherited through: B) <-- Simplified to just one line/item because there is only a single chain
I (Inherited through: C) <-- Simplified to just one line/item because there is only a single chain
J (Inherited through: A - F) <-- Simplified to just one line/item because there is only a single chain
K
  Inherited through: C - I
  Inherited through: A - F - J
X<T>
  X<A> inherited through: A
  X<B> inherited through: B
  X<J> inherited through: A - F - J

Also I think this feature may be particularly useful for interface hierarchies involving generics. There is often a need to resolve C#'s current l.imitation where it complains that the same generic interface is inherited more than once through different type parameters, which can lead to their unification. So, to resolve such issue when designing interface hierarchies it is very helpful to be able to easily see exactly through what inheritance chain such generic interfaces are inherited.

[wmjordan]

Build 7456 had introduced a terrible bug which caused the Surrounding with Snippet command to crash VS.
The new beta 7507 should have it fixed.

[fitdev]

Another related Super Quick Info improvement I want to propose is to reposition the where TypeParam : generic constraints from the type's title to where the information about type parameters is presented as shown below:

Because when you have many type parameters with complex constraints, it becomes quite difficult to find them in the long multi-line title.

And same goes for tooltips on generic type parameters themselves - they could be formatted better:

[wmjordan]

@fitdev

You are right.
I have the same thought about that, even before the first version of Super Quick Info was implemented, as well as #216 purposed by @laicasaane.
I'll try to re-implement the symbol title in the next version.

[wmjordan]

The previous version could still starve threads in the C# Interactive window.
Beta 7550 has rewritten the way how C# tagger postpones calling Roslyn, no more locks or blocking, asynchronous state machines will be created sparsely, which effectively reduces the number of threads concurrently created.

@fitdev and @laicasaane
Could you please take some time to download and test the beta and see whether it works well on your computer. If it works well, I will work on the C# Quick Info symbol title.

[wmjordan]

Well, there's a beta 7556, which performs a little faster than 7550. However, either 7550 or 7556 can not highlight submissions in C# Interactive window as previous version did. The new versions just highlight the most recent submission and former submissions will not get highlight any more.

I found that VS inevitably leaks memory resource, after opening and closing files, by creating a new instance without extension and observe its resource usage on my machine.

The recent VS preview version also has a bug when installing extension on multiple side-by-side versions of VS. I had both VS 2017 and 2022 on my machine. If I install Codist on both instance during one installation process, the extension installer will report the installation on both instances are success, however, the result is on the contrary--Codist just gets removed on all VS.

[wmjordan]

Beta 7572 should have fixed previous problem in 7556 by caching parsed results for recent commands.

@fitdev
Do you have ASP.NET projects on your computer?
Could you help test whether the recent betas work well on ASP.NET projects?

[fitdev]

I only have *.razor-flavored files, so no *.cshtml files if that's what you meant. But Codist did not seem to work well (poor syntax highlighting experience) the last time I checked.

[wmjordan]

*.razor files could not be improved. I installed Razor language service on my VS and found the content type of a Razor document does not appear to contain C#.

However, I haven't been working with web projects for quite a few years, and my work fellows all use VS Code to program their front-end projects. Thus I would not support C# highlighting in *.cshtml files.

[fitdev]

Just installed 7572. As you experienced yourself, I too had to install it 3 times for it to be installed on 2022 (I too have multiple versions, and it was only installed on the first one - 2017).

Checked razor files - no highlighting at all. It would be nice if you could try to add highlighting in at least the @code { } area.

[fitdev]

Could you help test whether the recent betas work well on ASP.NET projects?

So, if you were not talking about .cshtml or .razor files, what did you mean?

[wmjordan]

I tried some Razor files with @code{} area. No way to hack into them at this moment.

I will release a new version in near future despite of that, then go for the Quick Info request.

[wmjordan]

@fitdev and @laicasaane

There's a new version which has introduced a alternative style to display C# symbol signature in Super Quick Info (screenshot above). With that style, you can very easily spot out the name of the symbol, its member type, and its container symbol.

To activate the new style, select the "Use alternative style" in the Super Quick Info/C# options page.

[laicasaane]

@wmjordan The Base type line should be broken down too

[laicasaane]

@wmjordan Some symbols are highlighted in black

[fitdev]

I really like the alternative QuickInfo style. Great work! However a few issues / suggestions:

1. Type parameters should include generic constraints
2. Not sure about including the namespace below the type name (because assembly and namespace are already shown at the bottom of the tooltip, so this seems to duplicate information)
3. I think instead of . you should just use space in cases like: Nemapscae.class or Classname.field etc.

[laicasaane]

As stating here #216 I believe there should be an option to let us list the arguments of a method in several lines. This should be a separated setting.

[wmjordan]

Thank you all for the quick and reasonable feedback.

The Base type line should be broken down too

This has the same solution as #220.

Some symbols are highlighted in black

Will be fixed in the next beta.

1. Type parameters should include generic constraints

Thanks for reminding. Yes, I saw that and I will add it back later.

2. this seems to duplicate information

You are right. Even without the namespace info at the bottom, it is easy to hover the mouse cursor onto the symbol to see its namespace. I will remove it in the next beta.

3. instead of . you should just use space in cases like: Nemapscae.class or Classname.field

I will try that.

let us list the arguments of a method in several lines

Yes, I am facing this problem.

I am thinking whether it is possible to provide a better default behavior, good by default, instead of such an option.

[laicasaane]

This has the same solution as #220.

I mean, the Base type section should be represented in multiple lines rather than in a single line, just as the Interface section

The image will look somewhat like this:

SpawnPointEntity
{ } RpgWorld sealed class

Base type:
- WorldEntity<PositionValue, DirectionValue, AvailabilityValue>
- Entity<Group, Eid, PositionValue, DirectionValue, AvailabilityValue>
- Entity<Group, Eid>

[wmjordan]

There's a new beta which has addressed some problems in the alternative style of C# Quick Info.
It automatically changes method argument layout if there are more than 5 arguments.

[laicasaane]

if there are more than 5 arguments

Instead of a hard-coded number, we should have a setting for it.

I suggest breaking down arguments list into separated lines not only because of the number of arguments, but also the length of some type names which can be very long.

[fitdev]

In the current architecture of Codist, it is not so easy. I will think how to do that later.

Maybe during the tooltip creation process you can simply track that:

1. If the returns (or type parameters) appear right below the title (I think that's always the case for returns and always the case as long as there are type parameters) then set a flag that those are present.
2. When it comes to the next section - the one that normally shows documentation for returns or type parameters, simply check if appropriate flag has been set in step 1). If it was set, then simply do not render the section, and instead append documentation to the header.

In other words you only render the section with type params / returns documentation if the appropriate subsection is not present in the header below the symbol name. Otherwise you include documentation (if present) in the appropriate subsection below the symbol name header.

That's just my idea. Of course you know the architecture better so maybe I am wrong.

[wmjordan]

There's a problem when merging documentations into the signature part.

In some of my code, there are some members with long documentation for the return section (see the following screenshot).
(Yet typeParameters are usually short.)

If we merge the long return documentation up to the signature, the documentation for the method will be pushed out of sight.

[fitdev]

Yes, I agree. It is problematic. Perhaps we can do it for type parameters only then.

Also, a suggestion for the future - it would be nice if tooltips can be made pinnable (in a similar way to how symbol lists can be pinned).

[wmjordan]

Perhaps we can do it for type parameters only then.

Would it confuse the user why some documentations are on the signature part but others are below?
And from your screenshot, I saw that some type parameters had no documentation actually. Maybe it is possible to hide them to save some space.

it would be nice if tooltips can be made pinnable

Yes, I am considering a rewritten C# Quick Info. It is possible to do so in the future, maybe in version 6.7.

[fitdev]

Would it confuse the user why some documentations are on the signature part but others are below?

Personally I don't think it's a big deal. I think that if we can display a tooltip more effectively by utilizing space better it is still worth it. And yes, of course, if there is no documentation just hide it - no sense in wasting space.

Yes, I am considering a rewritten C# Quick Info. It is possible to do so in the future, maybe in version 6.7.

That's great!

BTW: When do you think you will rework interface inheritance representation as per my suggestion above? Version 6.7 too? I think it would be great if base classes would be included there too, so that it is clear through which base classes different interfaces are inherited (in case of classes).

[wmjordan]

rework interface inheritance representation as per my suggestion above

Your suggestion is valuable. However, I have to take some time to think about it.

[fitdev]

Another small suggestion. Perhaps you can add concrete type information for cases where members are inherited from base generic classes/interfaces:

For example here ContainerKey member (property) is defined in the base generic class MutablePrefixTreeNode<...> and the return type is specified as the generic type parameter TPrefixElement, which is correct for the base class, but a bit confusing for where this member is used (i.e. the derived class with concrete types (or perhaps different but more constrained type parameters substituted)). In the example above the actual type is string. So perhaps you could provide that information somewhere like: [ReturnsIcon] TPrefixElement is string or something like this. In other words in cases where type parameters come from some base class / interface, you show not only their name as defined in that base class / interface, but also show their actual concrete type (or type parameter if the class/struct/interface where they are used is generic too) based on the class/struct/interface where such members are used.

Also, maybe less important than the returns subsection, but the containing type name subsection might also benefit from generic type parameter resolution. I.e. perhaps the "resolved" / effective container type name can be specified in parentheses after the declared type name (or the other way around): MutablePrefixTreeNode<This, Tree, TPrefix, TPrefixElement> property => MutablePrefixTreeNode<This, Tree, TPrefix, TPrefixElement> (MutablePrefixTreeNode<This, Tree, FsPath, string>) property. Note the last 2 type parameters have been substituted with concrete /resolved type names from the current context. Or, perhaps even better, maybe you can always just show resolved type parameters whenever possible, i.e. just show MutablePrefixTreeNode<This, Tree, FsPath, string> property instead of MutablePrefixTreeNode<This, Tree, TPrefix, TPrefixElement> property (this way it will save space).

[wmjordan]

Good.
I will think about your suggestion and find a proper way to implement it.

Currently I am rolling back my VS installation to 17.4 preview 2.1, as I have just discovered that the recently preview 3 has a critical bug which causes a VS process related to Roslyn keeps consuming a lot of CPU resources.

[wmjordan]

There's a new beta which improves the display of type parameters.

After some contemplation, I decided to keep the type parameter documentation below the summary documentation.

add concrete type information for cases where members are inherited from base generic classes/interfaces

This has been implemented in the new beta, however, except for inherited interfaces.

[fitdev]

Currently I am rolling back my VS installation to 17.4 preview 2.1, as I have just discovered that the recently preview 3 has a critical bug which causes a VS process related to Roslyn keeps consuming a lot of CPU resources.

I am still on Preview 2 so has not noticed it. Thank you for letting me know.

I like the new beta. Type parameters now are more clear. Good work!

I decided to keep the type parameter documentation below the summary documentation.

Well, I have mixed feelings about it, but considering their documentation may be long too, perhaps the current way of displaying it is more appropriate.

[wmjordan]

There's a new beta which has many small tweaks and trivial enhancements.

[laicasaane]

There is an issue with the latest beta.

If a type is outside of any namespace (means it's in global space), Quick Info won't work.

ClassA in a namespace:

And ClassB in the global space:

[wmjordan]

Oh, I see.

There's a bug in the symbol location Quick Info. It will be fixed in the next beta.

[wmjordan]

There's a new beta version that has fixed global namespace problem. And more improvements.

[laicasaane]

Default values are not always raw literals. Many times we would want to "go to definition" by clicking on the type or the field name on Quick Info.

At the implementation site:

At the call site:

[wmjordan]

Many times we would want to "go to definition" by clicking on the type or the field name on Quick Info

Yep. I want that too. Yet I need time to implement that.

Today I upgraded VS to 17.4 preview 4. Again, weird CPU consumption issue occurred. Have to downgrade again...

[wmjordan]

There's a new beta version which enables click and go on expressions on the symbol signature.

However, those symbols in the signature expression can not be syntax highlighted--too much work...

[laicasaane]

Thanks! Just a bit of info on type is lost, but as long as we can go to definition I think it's fine.

[fitdev]

Just found a small bug in QuickInfo when showing method parameters with nullable value types:

[wmjordan]

Version 7670 has fixed the nullable type bug.

[wmjordan]

I kept the buggy 17.4 preview 4.

And today I added a function to monitor CPU as well as memory usage on the computer.
Now I can get notified when the roslyn bug occurs and CPU consumption goes high.

[fitdev]

Is the performance drop really serious on Preview 4? I am still on Preview 2. Should I wait upgrading?

[fitdev]

A small suggestion about QuickInfo Tooltips: It would be very nice if you could display number of implemented / inherited interfaces in the parentheses after Interfaces header: Interfaces (2 + 12 = 14): where the first number is the number of directly implemented/inherited interfaces, and the second number is the number of inherited interfaces (from base classes or other interfaces). Same for members: would be nice to display their count in parentheses.

[wmjordan]

Is the performance drop really serious on Preview 4?

I think so. The roslyn bug is terrible. It is a multi-threaded related problem which can drain one CPU core on your machine just doing nonsense. I reported with stack trace of the problematic threads, yet no one in MS replied.

Having been bugged once more, I reverted again...back to preview 2.1.

It would be very nice if you could display number of implemented / inherited interfaces in the parentheses after Interfaces header

It is not too big deal, but I am planning to rearrange the base type/interfaces on the Quick Info, thus this change won't live too long. I think it is possible to merge interfaces into the base types. For instance,

[fitdev]

Having been bugged once more, I reverted again...back to preview 2.1.

Thank you for letting me know. I will avoid upgrading for now then. Hopefully they will fix it when DotNet 7 RTMs in November.

[LuohuaRain]

I tried some Razor files with @code{} area. No way to hack into them at this moment.

I will release a new version in near future despite of that, then go for the Quick Info request.

Mark dotnet/razor#8642
Maybe?