Outline view icons are missing visibility / token modifier details - How can we change that?

[travkin79]

Comparing the icons used in the traditional CDT outline view with that of CDT LSP outline view, there is a lack of information in the CDT LSP outline view: the classes', methods', and attributes' visibility, i.e. public / private / package) is not shown. It seems, the reason are limitations in LSP4E. Im thinking about how to add these details to LSP4E. Could someone give me some advise?

CDT outline view example:

CDT LSP outline view example:

Java outline view example for similar code:

C++ code example:

#include<iostream>
using namespace std;
 
class Circle
{
    private: int diameter;
    
    public: 
        double radius;
         
        double  compute_area()
        {
            return 3.14*radius*radius;
        }
    
    protected: double compute_circumference() {
        return 2.0*3.14*radius;
    }
     
};
 
int main()
{
    Circle obj;
     
    obj.radius = 5.5;
     
    cout << "Radius is: " << obj.radius << "\n";
    cout << "Area is: " << obj.compute_area();
    return 0;
}

LSP4E has a SymbolsModel used, e.g. by CDT LSP, for the outline view. The method org.eclipse.lsp4e.outline.SymbolsLabelProvider#getImage(Object element) returns the icons, calculated by org.eclipse.lsp4e.ui.LSPImages#imageFromSymbolKind(SymbolKind kind) based on the kind of the element in the outline view. The kind is something like a class, a method, a field, or a property. The elements' details / token modifiers like visibility (public / private / package or package visibility in Java) seem not to be considered here. It seems, a DocumentSymbolWithURI that an icon is looked up for, does not have any details about visibility, e.g. some tags set on the DocumentSymbolWithURI.

Do I miss something? Do we have to send additional requests to the language server to receive the details about visibility (e.g. using the LSP endpoint textDocument/semanticTokens)? Is visibility supposed to be illustrated by decorator icons instead of different element icons like in CDT and JDT?

[rubenporras]

I suspect also one would need to use semantic tokens, as you say, but the standard list is defined in https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#semanticTokenModifiers
and does not contain private/protected/public.

Nothing stops a language server and a client to support additional modifiers, but they are not part of the predefined set.

I do not know why the spec is so restrictive (you will find several issues in GitHub if you look for it), but since it is so restrictive, I think a Java specific solution should not be part of the basic LSP4E plugin. One could be prepared tough in the LSP4E JDT project, if someone can contribute it.

[travkin79]

Hi @rubenporras,
Thank you for the quick reply and your opinion on that.

I guess, the visibility modifiers are too language-specific why they might be left out of the LSP standard.

According to the spec, a language server could add custom token modifiers, declaring them in the SemanticTokenLegend, right?

In my case, I want to add visibility details for CDT LSP, so I guess, clangd would need some kind of extension to support that, right?

I think, in that case you're right. This feature has to be implemented in a language-specific plug-in.

@ghentschke, FYI

[mickaelistria]

This IMO should be discussed on the LSP spec to include a concept of "visibility", just like it has a concept of "kind", and the response of the symbols request could include that.
I'm not sure it would have to be language-specific: just like kind, the spec could introduce an enum covering 99% of the languages with less than a dozen relatively general values.

So I think best is now to open an enhancement issue to the spec, maybe even with a PR proposing a change, and link it back there.

[travkin79]

So I think best is now to open an enhancement issue to the spec...

Good point, @mickaelistria.

I checked existing issues on the spec and it turns out, there is already an issue and a related discussion proposing a more general approach using SymbolTags that are used in DocumentSymbol and are already part of the released spec. What is still missing are the concrete tag values for most of the languages and use cases, i.e. public, private,... The only predefined SymbolTag value is deprecated.

I'm not sure it would have to be language-specific: just like kind, the spec could introduce an enum covering 99% of the languages with less than a dozen relatively general values.

I fully agree.

I think, we should continue the discussion on the spec and come back to LSP4E as soon as there is a need to adopt a new spec version.

[mickaelistria]

As a temporary workaround, you may add some infos in the details: for example adding emojis such as 🟢, 🟧, ⭕... to somehow express visibility. I'm not sure of whether such a convention alredy exist to efficiently express visiblity, you may need to design one.

[travkin79]

That's an interesting idea, but I think, I would have to modify clangd to do so. 😓

[travkin79]

Update
In the meanwhile, I created a few pull requests and there is a clangd / llvm PR draft that creates additional symbol tags for C++ code using my LSP PR suggestion. I've implemented a prototypical label provider for the LSP4E outline view and there are a few open questions. The PRs are work in progress and you can influence the final result. Reviews are appreciated.

Involved PRs:

• LSP Specification: [#98] Add SymbolTag values for access modifiers and other modifiers microsoft/language-server-protocol#2003
• clangd / LLVM: [clangd] Support symbolTags for document symbol llvm/llvm-project#113669
• LSP4J: Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) eclipse-lsp4j/lsp4j#856
• LSP4E: Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149

Exemplary outline view for a C++ code example

Open questions

• Did I suggest the right symbol tags? Can we start with these? ([#98] Add SymbolTag values for access modifiers and other modifiers microsoft/language-server-protocol#2003)
• Is it ok to use a visibility overlay icon (in the top left corner) for each symbol kind image instead of creating unique images for each combination of symbol kind and visibility, similar to JDT?
• I'm creating at most 4 overlay icons for any symbol kind image (see guidelines) and sometimes a fifth so called underlay icon for deprecated elements. I guess, we need some kind of caching. Is my caching concept good enough? Do we have to explicitly dispose the overlay images, too, or is it enough to dispose the DecorationOverlayIcon? (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149)
• I think, it's desirable to make label calculation from LSP4E adaptable by other Eclipse plug-ins for concrete languages or language servers. Should we offer some extension points for that purpose (maybe in a separate PR)?
• I'd prefer to add some unit tests for the new label provider and related code. How could we automatically test the overlay image calculation? (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149)
• I'm not sure about the chosen overlay icons for declaration and definition (small empty or filled triangles, see screenshot above). Are there any better suited overlay icons available in some open source Eclipse plug-in? (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149)
• Are there better overlay icons than a lock symbol for the symbol tag "read-only"? (Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149)