Skip to content

Generate Code Cities using the Language Server Protocol

Pre-release
Pre-release
Compare
Choose a tag to compare
@github-actions github-actions released this 02 May 18:09
· 1815 commits to master since this release
pr-727
352dab5
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

This release incorporates the changes by @falko17 from pull request #727.
Builds for Windows and Linux are available below.

Summary

This PR implements the main part of my master's thesis: It allows users to generate code cities based on information provided by LSP language servers. (Integration of LSP beyond that, e.g., in code windows, is not yet implemented.)
There are also several other changes, such as a determinate progress spinner—see details below.

Supported languages

Below are all the languages SEE supports now. For all of these languages, there's at least one language server configured in LSPServer.cs for which I've tested and confirmed that code cities can be generated with it.
For each language server, a link has been provided to installation instructions for it. It will be shown if it is detected that the server is not installed.

Programming languages

  • C
  • C++
  • C#
  • Dart
  • Go
  • Haskell
  • Java
  • JavaScript
  • Kotlin
  • $\LaTeX$
  • Lua
  • MATLAB
  • PHP
  • Python
  • Ruby
  • Rust
  • TypeScript
  • Zig

Miscellaneous languages

  • JSON
  • LaTeX
  • Markdown
  • XML

Note

These are just the languages I've tested. If there are any other languages for which there's interest of adding support to SEE, it should be rather simple to add them to LSPServer.cs.

Details

  • A new LSPGraphProvider has been added, along with various related components (LSPImporter, LSPHandler, LSPLanguage, LSPServer). This makes up the majority of the changes for this pull request and is the biggest step of #686.
    • LSPLanguage and LSPServer are purely data models to represent languages and language servers for the user to choose from, respectively.
    • LSPHandler handles the actual communication with the LSP server and abstracts over/wraps OmniSharp's LSP client.
    • LSPImporter contains the actual main algorithm responsible for creating a code city, using a previously set up LSPHandler.
    • I won't go into more detail on each of these here, as it would take up a lot of space, and I plan to do it in the master's thesis anyway.
    • An important caveat: Due to a bug in OmniSharp that seems time-consuming to fix for now, we cannot retrieve the call hierarchy (i.e., outgoing calls) for nodes. Hence, these will only show up as "reference" edges.
  • For the LSP import to work efficiently, an interval tree has been implemented as an augmented KD-tree.
    • This is used to match node ranges to the most "fitting" nodes.
    • Tests have been added to make sure this works correctly.
  • A progress bar has been added in the editor for code cities. This can be used to signal the progress of an ongoing graph creation process to the user.
    • For this purpose, a callback has been added that graph providers can use to report their progress.
  • A determinate progress spinner (i.e., one that updates based on progress reports) has been implemented. It can be used as LoadingSpinner.ShowDeterminate("Loading something...", out Action<float> updateProgress, where updateProgress can be called with a float from 0 to 1 to indicate the progress percentage.
    • For loading processes in general, the process name is now shown below the loading spinner rather than when hovering above it. This makes it more legible to the user what is happening.
  • Cooperative cancelling has been implemented for graph providers. That is, ongoing asynchronous processes can now be cancelled using a CancellationToken. Currently, loading processes can be canceled by clicking on "Reset data".
  • A general representation of Ranges has been implemented into Attributable. Internally, these are represented as four integers (start line, end line, start character, end character).
  • The containment logic for ranges has been fixed, as there were previously some subtle errors. Tests have been written to catch such errors in the future.
    • Additionally, ranges are now (non-transitively) comparable in order to find out which of two ranges takes up more characters.
  • A workaround for an upstream bug in the CI has been implemented by reverting to an earlier version of the github-script dependency.
  • Unity has been updated to 2022.3.26f1.
  • As a result of the above changes, the following NuGet dependencies have been added:
    • OmniSharp's LSP implementation to use as an LSP client
    • Supercluster.KDTree for an efficient kd-tree implementation for the LSP import algorithm. It has been augmented for use as an interval tree in the class KDIntervalTree<E>.
    • Markdig as a Markdown processor for LSP-provided user-facing text. Currently, the markdown is simply converted to plaintext, but in the future, we can use Markdig to convert it to TextMeshPro rich text tags.

See original pull request for details.

Contributors

falko17
Assets 4
Loading