This requires an implementation of the DocumentSymbolProvider and WorkspaceSymbolProvider interfaces. Relevant code will need to be added to PowerShell Editor Services to support this behavior.
Assigning Keith since this is for the feature he was interested in helping with. I'll provide more details privately.
Would this allow for symbols search and goto for PS 5.0's classes and enums?
Yep, that's something we haven't finished yet. Seems like you had commented on the Editor Services issue for this a while back:
https://github.com/PowerShell/PowerShellEditorServices/issues/14
Sorry about that :/ I'll see if I can get some help to get that implemented for the 0.8.0 release!
Any updates on this? I have version 0.9.0 now and this doesn't seem to work.
Any updates?
This is a big missing piece for me. I try to do most of the development as classes, and wrap them with functions to get the task based abstractions.
But that means navigation is only available for a minor subset of my code.
Same here, enums are not 'colored' at all (plain white).
Just for the record, @mmajcica, enums being not colored is an EditorSyntax issue. That's all the syntax highlighting. This issue is opened there:
https://github.com/PowerShell/EditorSyntax/issues/29
Thank you all for your patience! Classes and enums are lacking at the moment for sure. The best thing to do is 馃憤 issues as that is one factor we look at for priority.
Go to definition for class and class methods do not work on ps core
Go to definition for class and class methods do not work on ps core
That's a 2.0.0 feature. Compatibility with PowerShell v3/v4 mean we can't use new APIs that expose class ASTs. So no class symbols until we drop v3/v4 support.
@rjmholt, that doesn't sound correct. That doesn't sound like a smart thing to do, to not be able to use a new API because you must still support an old API. At that rate, we'd never have moved past DOS. If this is such a problem, maybe both versions of the extension should be made available, but I would like to think that should not be needed.
Agreed, it would be much better to provide both versions. Right now we're managing with some difficult with relatively small code base, but can't imagine how complex it will be as our code base gets larger.
@rjmholt Should I expect go to definition to work now if I'm using the 2.0 preview extension? Just installed and it doesn't appear to be working.
Not yet. First step is dropping support for v3 AST which 2.0 preview does. Next step is to add support for classes (and enums).
Agreed, it would be much better to provide both versions. Right now we're managing with some difficult with relatively small code base, but can't imagine how complex it will be as our code base gets larger.
Precisely the problem we face in this code base. We've been trying to make the code more maintainable since we're spread thin across 30k lines of C#, and tangling things up in compile-time macros means the code gets harder to reason about and we have to juggle multiple DLLs to load at runtime.
The decision to not compile a different DLL for PS v3/4 (compared to PS v5) was made by @daviwil in an earlier iteration of the project, but adding the capability back in presented a significant architecture-changing work item for new maintainers.
Anyway, now that PSReadLine means we are incompatible with PS v3/4, we can feasibly move back to an AstVisitor2 implementation without much complexity. But there are other things that need fixing first. It's the kind of thing that a community contribution would probably add much faster.
This will be trickier than anticipated. Uncommenting the code that already existed didn't really do much. Here's what it has:
Here's what it's missing:
References here means actually going through and figuring out that a symbol ([MyClass]::Foo) is a reference of a class symbol (in this case a property of class MyClass). This will be tricky with non-static members... and will probably be best effort.
So yeah. Lot's to do.
Most helpful comment
Precisely the problem we face in this code base. We've been trying to make the code more maintainable since we're spread thin across 30k lines of C#, and tangling things up in compile-time macros means the code gets harder to reason about and we have to juggle multiple DLLs to load at runtime.
The decision to not compile a different DLL for PS v3/4 (compared to PS v5) was made by @daviwil in an earlier iteration of the project, but adding the capability back in presented a significant architecture-changing work item for new maintainers.
Anyway, now that PSReadLine means we are incompatible with PS v3/4, we can feasibly move back to an
AstVisitor2implementation without much complexity. But there are other things that need fixing first. It's the kind of thing that a community contribution would probably add much faster.