Implement IDE's breadcrumbsInfoProvider EP

[SCWells72]

I'm not 100% sure which LSP capability would best lend itself to this EP, but the information is definitely there. Basically it would just need to be able to discern the containing declarations up to the file itself exclusive. That would enable both more detailed breadcrumbs and sticky lines in 2024.1+.

[angelozerr]

It doesn't exist a specific LSP features for that, but vscode implement that by using the LSP textDocument/documentSymbol feature(I believe)

[SCWells72]

Yes, that seems like the most obvious way to implement it. You'd just need to get the document symbols for the file, find the parent symbol for the current caret, and work your way up from there. Seems like it should be pretty straightforward actually.

[SCWells72]

I played with this a bit this morning and hit a pretty solid snag. breadcrumbsInfoProvider very specifically wants a true PSI tree as its interface is based on evaluating elements in that tree to determine which correspond to breadcrumbs. However, with LSP-supported languages, there is no PSI tree. It's generally either a plain text file or a TextMate file.

I'm going to inquire on the plugin dev discussion group whether there might be some way to do this without a true PSI tree, and I'll of course be brainstorming the same thing while waiting for responses there.

UPDATE: I may be able to do it by overriding #getChildren() and #getParent() with fake PSI elements that follow the structure from textDocument/documentSymbol. Hopefully more promising results to share shortly!

[SCWells72]

Well, bummer. That didn't pan out either. Here's what I just posted to the plugin dev discussion forum:

Has anyone successfully implemented the breadcrumbsInfoProvider EP for a file type that doesn't have a true PSI tree? I'm trying to implement that EP for a file type where structural information is available from an external source (LSP), but there's not actually a PSI for the file. For most other EPs, you can use the file and current offset within the file, but this specific EP basically starts by asking whether or not a specific element in the PSI tree represents a crumb, and if it does, it then queries the label/tooltip text/icon for that crumb. Obviously that doesn't work when there's not a PSI tree to traverse.

I noticed that the interface does have getParent() and getChildren() methods that it seems would support this use case, but getChildren() has no usages and is documented as "Reserved for future releases. Not supported yet."

So...is this possible right now, or will it have to wait until getChildren() is wired into breadcrumb processing?

I'll post any new information I might receive here to help structure further work on this enhancement.

[angelozerr]

Thanks Scott to investigate the issue.

A thing which is very important is about performance. DocentSymbol can be very big with large file and can take time to load it.

We need to take care of this constraint to avoid freezing IJ.

[SCWells72]

The good news is that I have a local proof-of-concept with breadcrumbs working for both the breadcrumb trail (bottom of the editor tab) and sticky lines (top of the editor tab):

The bad news is that while the basic breadcrumb trail went pretty smoothly, what I've had to do to make sticky lines work basically ends up resulting in a fake pseudo-PSI structure for the file based on the one created for LSPDocumentSymbolStructureViewModel that's causing all kinds of issues with other IDE features.

I can certainly separate these two so that basic breadcrumb support is ready in a low-risk manner, but before doing that -- and while my other pending PRs are already working their way through the queue anyway -- I'm going to see if I can iron things out a bit so that this take pseudo-PSI tree actually gives us what we want.