ppisl opened a new pull request #3525:
URL: https://github.com/apache/netbeans/pull/3525


   This is the outlineview implementation not only for Groovy files, but for 
all GSF languages that are/will be enabled in the Vs Code extension. At the 
moment it is for Groovy files and YAML files that have `application` or 
`bootstrap` prefix.
   
   The implementation requires adding two interfaces to the LSP API. Clients 
can implement and register a `StructureProvider` into `MimeLookup` for a given 
mimetype. `StructureProvider` provides a list of top symbols to be displayed in 
the outline view. The symbol structure is composed of `StrctureElements`. 
   
   StructureElements are then translated into `DocumentSymbol`s on the VSCode 
API side, which are displayed in the outline view and also in Go to a symbol 
(CTRL+SHIFT+O by default). `DocumentSymbol`  has two methods `getName()` and 
`getDetail()`, which both return `String` and the resulting compound text is 
displayed in the outline view, where the text returned by `getName()` is 
slightly larger than the text returned by `getDetail()`. On the other hand, 
only the text returned by `getName()` is displayed in **Go to a symbol**. The 
`DocumentSymbol` documentation says that `getName()` should return the name of 
the symbol and `getDetail()` should return the detail of the symbol, such as 
the signature of the function. 
   
   Currently in outline view we display the signature as the symbol name and 
the type as the symbol detail for java files. This means that in Go to a symbol 
we display not only the names but the symbol, but also signatures with the 
types of the function parameters, which can affect the symbol search.
   
   On the other hand, the java extension offered by Microsoft does the same. 
However, in my opinion, `getName` should really return only the name of the 
symbols and this would make the search in Go to symbol easier. 
   
   This PR also moves the existing functionality that provided outline view for 
java files outside the LSP server. The JavaStructureProvider implementation is 
now in the java.editor module, which already has a dependency on the LSP API.  
Provider should logically belong to java.navigation module, but this module is 
not enabled for VsCode extension and if we enable it, it brings with it 
dependency on WindowsSystem.API, which is not sufficient now.  


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Reply via email to