Codist 6.7 Beta

[wmjordan]

Download

Codist 7983

Codist 7977
Codist 7963
Codist 7933
Codist 7924
Codist 7923
Codist 7912
Codist 7909
Codist 7906
Codist 7856
Codist 7831
Codist 7819
Codist 7805
Codist 7801
Codist 7797
Codist 7794
Codist 7787
Codist 7760
Codist 7749
Codist 7736

What's New

• General
  • Added google to default search engines (7801, [Suggestion]: Add default search engine for Google #226)
  • Fixed improper configuration saving after initial load (7923, 代码样式不显示 #229)
  • Added a command to call refactorings provided by Codist (7977)
• Syntax Highlight
  • Made compatible to VS 17.5 preview 1 (7787)
  • Added highlight style for private members (7819)
• Resource Monitor
  • Added option to display network adapter throughput per second (7736)
  • Added hover to display top CPU usage processes to CPU monitor control (7760)
  • Added option to customize task manager that launched after clicking monitor controls (7760)
• Super Quick Info
  • Added implementation or declaration type info in interface list (More detailed list of interfaces in C# Quick Info #222, 7736, 7909, 7912, 7933)
  • Changed behavior of the symbol signature icon in alternative style to display commands for generic type (7749)
  • Merged some C# Quick Info options about type inheritance (7749)
  • Displayed GetEnumerator method for foreach statement when hovering on in keyword (7760)
  • Enabled Click & Go for C# label (7760)
  • Added a new option to display all enum fields on C# Quick Info (7794, 7797, 希望枚举类型的tooltip提示上，能展示出所有值 #225)
    
    
  • Fixed symbol signature was not wrapped in C# Quick Info (7923)
  • Added fallback for a bug in Roslyn which prevented C# Quick Info from applying Click & Go for signature value nodes (7963)
• Smart Bar
  • Displayed symbol analysis commands for type argument for generic types with arity=1 (7749)
  • Enabled symbol analysis commands for predefined types on C# Smart Bar (7749)
  • Enabled reorder refactoring for argument type on C# Smart Bar (7749)
  • Enabled Extract Method refactoring when debugging (7760)
  • Optimized behavior of Join Lines command (7963)
  • Added quite a few refactoring methods to C# Smart Bar (7787, 7805, 7819, 7831, 7856, 7906, 7923, 7933, 7963)
    
    
  • Added a new command to select all occurrences of current symbol in active document (7856)
    
  • Added Copy without Indentation mode to the Copy command (7924)
    
    For instance, select the following code, which is indented with 4 preceding tabs, then press Ctrl before clicking the copy button.

				if (line.Extent.IsEmpty) {
					spans.Add(line.Extent);
				}

Result:

if (line.Extent.IsEmpty) {
	spans.Add(line.Extent);
}

• Symbol Analysis Menu
  • Changed style of symbol name in symbol analysis menu (7749)
• Navigation Bar
  • Menu would pop up from wrong window when document windows were arranged with keyboard (7906, Navigation bar dropdown menu open at old tab location when moved tab with keybaord shortcut #228)
  • Added unit test commands to C# NaviBar nodes (7963)
  • Made Ctrl+Clicking on type nodes on C# NaviBar to go to type definition (7983, [Feature Request] Add ability to have Key binding for quick move to Definition from nav-bar #233 )

[fitdev]

Just a quick feedback on 7794 (7795 - could not download because it said file was not found):

For some reason the constructors, as well as readonly struct types names in super quick infos are colorized as regular structs (not as readonly structs - I have 2 different styles for them).

[wmjordan]

@fitdev What's the VS version you are on?

I reproduced your issue.

The VS highlight system appears to have difficulty to merge styles together.
And I find that sometimes some highlight styles can not be applied at all.

[fitdev]

I see. It's not a bid deal, as I am still not sure if I want to distinguish between readonly and regular structs.

I am on VS 17.5 preview 1

[wmjordan]

Congratulations!

You are on the problematic version eventually.
I've provided them the stack trace and probable cause of the problem, but they could not yet solve it.
Now that bug has been released with 17.4.

Thus I posted the issue to the Roslyn project, which was probably related.

I suggest you turn on the CPU resource monitor component by checking the "Monitor CPU" checkbox in the Codist/Display options page and see whether you encounter that problem too. When it occurs, the CPU consumption rate will remain continually as high as a core is engaged.

[fitdev]

Thank you for letting me know. I was concerned about this actually. But so far I have not yet noticed anything yet, but then again I was not working for the last 10 days. Next week I will get into it and see if occurs. So far I had VS just sitting there with solution loaded and it did not consume any more CPU than it did before, but perhaps it will once I start typing in the editor.
I do monitor CPU and other resources all the time through Process Hacker app, and will let you know if I have the same issue.

[wmjordan]

There is a new beta version with more code refactoring commands in C# Smart Bar.

[fitdev]

Just a quick report on another weird colorization:

All struct names should be Pinkish (the same color as for ByteSize since they are all readonly structs).

[wmjordan]

It is really a challenge to have the highlight work......as from time to time, VS changes its way...

[wmjordan]

readonly structs

The problem is the record struct, which somehow has a higher precedence over the "C#: Read-only struct", no matter how I change their priority orders. You have to change the color of the record struct name.

[fitdev]

Thanks for the suggestion. Yes, I will do that. Though it does raise a more general interesting question: how do you resolve such conflicts in general like when you have 2 modifiers applied which one takes precedence? I guess it is not something you can control in VS now. Maybe they will add some API in the future to control this.

[wmjordan]

I guess it is not something you can control in VS now

You are right.
It is quite limited.
I somehow managed to find a way to control SOME merged styles. However, to fully support that, lots of work has to be done. And the record struct name's precedence is still a mystery

[fitdev]

A small issue with showing interface inheritance in superquick infos:

For clarity: on the screenshot, the class inherits from a base class and implements just one interface (all other interfaces come from either the base class(es) or their interfaces).

For classes it shows all interfaces as if they were explicitly declared on the class itself, instead of showing that they are actually coming from the base class as shown on the screenshot. Ideally, it should show interfaces with information where they are declared explicitly - base class, base of the base class, etc., or some interface name (it is common that some small interfaces are only declared on (inherited by) larger interfaces and not classes). So the tooltip should clearly show this, i.e. where a particular interface is "coming from".

[fitdev]

Another small thing: I noticed that bold style for type declarations does not work (they are not bolded). I would like all type declarations like public class Foo {} to be bold, and there is an option for this in Codist, but it does not affect how it is displayed in the latest VS.

[wmjordan]

So the tooltip should clearly show this, i.e. where a particular interface is "coming from".

I am sorry that I have to reconsider it.
The screenshot is showing information about a class. From the prospect of object-oriented programming, a class implements some interfaces--that is what we mostly care about when we use that class.

[wmjordan]

I noticed that bold style for type declarations does not work (they are not bolded)

That's weird. I have never experienced this, even when the highlight was somewhat broken sometimes (#227) here.
The C# Declaration was by default Bold (see below) on Codist. Have you UNCHECKed the Bold box in another syntax style?

[fitdev]

The screenshot is showing information about a class. From the prospect of object-oriented programming, a class implements some interfaces--that is what we mostly care about when we use that class.

I understand that but the way it currently appears on the screenshot is completely redundant: yes, it is true that FsTreeEntryDir class implements all those interface, but it does so through its base class (i.e. FsPathTreeDir). So then why does the tooltip show all these interfaces as coming directly from FsTreeEntryDir (i.e. current class), instead of showing them as coming from FsPathTreeDir base classes (or its base classes as appropriate)?

In other words, the : FsTreeEntryDir<This, Tree>s at the end of most interfaces in the screenshot above are unnecessary, since the information they provide is not correct / unneeded (those interface come from the base class(es), not the current class). And if, as you suggest, for classes you do not want to show the fact that certain interfaces are implemented / inherited through their base class(es), then why have this extra line ending at all, since they all show the same thing (: FsTreeEntryDir<This, Tree> in this example) regardless of where the interface is actually coming from?

[fitdev]

Have you UNCHECKed the Bold box in another syntax style?

No, here's the screenshot:

Ideally I would want everything underlined in red to be bold. But at the very least, the name of the type with generic parameters should be bold. Or is this something not possible?

I am sorry I have upgraded VS to the latest preview and migrated my VS profile, and maybe that has screwed up certain things, so maybe I am asking for something which was never there in the first place.

[wmjordan]

From the above screenshot I think Codist is doing what is designed to do.

It won't have everything in the declaration node styled. It only applies the style to the name of the declared member, demonstrated like the following screenshot, where the member declaration has an enlarged font size specified.

[wmjordan]

I understand that but the way it currently appears on the screenshot is completely redundant: yes, it is true that FsTreeEntryDir class implements all those interface, but it does so through its base class (i.e. FsPathTreeDir). So then why does the tooltip show all these interfaces as coming directly from FsTreeEntryDir (i.e. current class), instead of showing them as coming from FsPathTreeDir base classes (or its base classes as appropriate)?

How do you think it should be displayed like, an example?

[fitdev]

I think Codist is doing what is designed to do.

It would be ok if it would stylize just the type name, but it does not make bold even that. The reason why ion the screenshot the type name looks a bit bold is because I use a slightly bolder font for all my (user types). But the bold (Declaration) style in the above screenshot was NOT applied to the type name. It's not a big deal, but if you could figure this out it would be nice.

How do you think it should be displayed like, an example?

Well, in my example, in the tooltip where it has: : FsTreeEntryDir<This, Tree>, instead it should have FsPathTreeDir<This, Tree> because this is where those interfaces are coming from (i.e. coming from the base class: FsTreeEntryDir<This, Tree> inherits FsPathTreeDir<This, Tree>)! That is the name of the class / type that appears after the : when displaying a list of interfaces for a class or struct should be the type (either some base class) or the interface where that interface is defined.

Maybe the case of structs is a more complicated one, because a single interface can be implemented by more than one other interfaces, through which a particular struct will implement it, but at least it should work for classes: if the interface is NOT defined as being implemented by the class, then it is coming from its base class (or the base of the base, etc.), in which case, what should appear after : next to that interface is not the current class, but it's base class (or base of base - wherever the interface is actually implemented / "brought in").

[wmjordan]

Well, in my example, in the tooltip where it has: : FsTreeEntryDir<This, Tree>, instead it should have FsPathTreeDir<This, Tree> because this is where those interfaces are coming from (i.e. coming from the base class: FsTreeEntryDir<This, Tree> inherits FsPathTreeDir<This, Tree>)!

Please try the new beta and see whether it is doing what is supposed to do.
If it doesn't, please show me the declaration code of relevant classes and interfaces.

[fitdev]

Thank you for the new version! It is a step in the right direction, however there are 2 issues still:

1. For some reason interfaces defined on the immediate base class (FsPathTreeDir<This, Tree> in this example) are still shown as if they were defined on the current class (i.e. on FsEntryTreeDir<This, Tree>). But they are not defined on the current class - they come from the base class. The only interface defined on the current class is IFsEntryTreeDir<This> and is shown correctly as such (no : after interface name because it comes from the current class directly).
2. If you compare this tooltip to a previous tooltip, some interfaces are missing. The missing interfaces are those that are not explicitly defined on any class (they come from other interfaces). I think for those there can be 2 possibilities:

• Use the same behavior as you do for superquickinfos for Interfaces, i.e. you show after : which interface the interface being listed is "coming from"
• OR: Since we are showing quickinfo for a class, maybe show the base-most class name that implements the interface's containing interface.

Below is the breakdown of how it should work:

class A : B, IA { }

class B : C, IB { }

class C : IC { }

interface IA { }

interface IB : IExtra1 { }

interface IC : IExtra2 { }

interface IExtra1 { }

interface IExtra2 { }

The superquick info for A, interfaces section:

• IA
• IB : B
• IC : C
• IExtra1 : B (because it comes from IB which comes from B) OR IB (because it comes from IB)
• IExtra2 : C (because it comes from IC which comes from C) OR IC (because it comes from IC)

[wmjordan]

I reverted to the previous version, it was showing the correct info for A.

Could you take the trouble of giving the definitions of your classes and interfaces in problem?

[wmjordan]

Could it be the problem like the following IA has already inherited from IB?

class A : B, IA { }

class B : C, IB { }

class C : IC { }

interface IA : IB { }

interface IB : IExtra1 { }

interface IC : IExtra2 { }

interface IExtra1 { }

interface IExtra2 { }

Then the Quick Info will display that A has implemented IB and IExtra1.

[fitdev]

Could it be the problem like the following IA has already inherited from IB?

You are right. This is what was going on.

However to merely show IB : A is confusing because when you inspect declaration of A you will find : IA only and not ..., IB. So I suggest that in the case of A (i.e. the current class) we just show 'IB : IA' because IB is implemented by A indirectly through IA, and there is no point in duplicating the fact that A consumes the interface directly (i.e. no point in showing 'IB : A' because we already know that we are display superquickinfo for A). So better to use the same style for interfaces that are directly declared as implemented by a class (i.e. no ': Classname' after interface name, except that because an interface is not directly declared by a class but comes to it via intermediate interface, there should be ': IntermediateInterfaceName' instead).

So, elaborating on a more complex case, I suggest:

Given:

class A : B, IA { }

class B : C, IB, IExtra2, ICommon, IBOnly { }

class C : IC, ICommon, ICOnly { }

interface IA : IB { }

interface IB : IExtra1 { }

interface IBOnly : ICommonForBandC { }

interface ICOnly : ICommonForBandC { }

interface IC : IExtra2 { }

interface IExtra1 { }

interface IExtra2 { }

interface ICommon { }

interface ICommonForBandC { }

The SuperQuickInfo for A should show:

• IA
• IB : IA (it comes into A through IA : IB, but there is no point in showing just IB : A, and instead we are being more helpful and show through which interface IB comes into A, and in this case it comes through IA).
• IC : C
• IExtra1 : IB (it comes directly into A through A : IA : IB : IExtra1, but we are being more helpful here and instead of showing IExtra1 : A we show which immediate interface it is coming from)
• IExtra2 : C (because it comes from IC which comes from C)
• ICommon : B (even though both C and B have this interface, we pick the most derived (closest) class.
• IBOnly : B
• ICOnly : C
• ICommonForBandC : B (just as with ICommon we pick the most derived class which contributes the interface (whether that class explicitly has the interface in its declaration or implements it through another interface or not) - in this case it's B

I think this covers all the cases including multiple interface inheritance.

I still think that in the future it would be helpful to provide even more information about the exact inheritance paths for interfaces, but for the moment this behavior would be great!

[wmjordan]

Thank you for helping out.
Please test the new version.

[fitdev]

Wow! You are so fast! Yes, this new version is great! Exactly what I was hoping for!

One small thing though, if possible, regarding the ordering of interfaces in the list, using the above example:

class A : B, IA { }

...

interface IA : IB, IAExtra { }

...

interface IAExtra { }

IAExtra is indirectly implemented by A through IA. Is it possible for all such cases to appear right after IA in the list (i.e. after the interfaces that are directly present in the class' declaration) but before interfaces that come from base classes?

[fitdev]

BTW, in my case I often deal with classes that are like 5 or 6 levels deep in inheritance hierarchy and have 40+ interfaces. So this feature is very helpful! Thank you!

[wmjordan]

the ordering of interfaces in the list

I observed that before uploading the last beta. However, it will make the code more complicated at my first thought.

Furthermore, I am not very sure whether the current implementation works well with base types either.
Please email me if you find something wrong.

[laicasaane]

@wmjordan I'm using the latest version:

In Dark theme texts should be white.

This tooltip background should be dark.

[wmjordan]

@laicasaane
Please download the new beta.

[wmjordan]

I am about to release the final version in several days.
Please download and help test the latest beta.

[fitdev]

I noticed there are a lot of new refactorings in Codist. Is there a way to quickly invoke the refactoring menu with a single keyboard shortcut (without having to first show the Smart Bar and then use the mouse to select the refactoring menu)?

[wmjordan]

Is there a way to quickly invoke the refactoring menu with a single keyboard shortcut

Hi, please download the new beta.
You can assign a keyboard shortcut for that function.

[laicasaane]

Could you please add an option to delay showing quick info for some time? It often gets in the way when I try using multiple carets. 😂

[wmjordan]

delay showing quick info

It does not seem to be viable. No API to do so.

[wmjordan]

It often gets in the way when I try using multiple carets

@laicasaane
There's an option to suppress the Quick Info when Ctrl key is pressed.

[laicasaane]

Thanks, I will try it now.