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. 😓