It was an incredible learning experience with GSoC and Godot Engine! I can’t believe three months have passed so quick that I’m writing this final report, summarizing all the exciting work I did in these Summers (27 May - 26 Aug 2019).
Project Name: GDScript Language Server
Student: Ankit Priyarup (@ankitpriyarup)
Mentors: Geequlim (@geequlim) and Jiacheng Lu (@jason0214)
Repositories:
- Student Server Working Branch: https://github.com/ankitpriyarup/godot/tree/lsp
- Mentor Server Working Branch: https://github.com/GodotExplorer/godot/tree/gdscript-lsp
- Student Client Working Branch: https://github.com/ankitpriyarup/godot-tools/tree/lsp-client
- Mentor Client Working Branch: https://github.com/GodotExplorer/godot-tools/tree/lsp-client
Pull Requests:
Integrated script editor in Godot lacks features found in editors like VS Code, Sublime, Emacs, etc. These editors are also more popular among developers and therefore are better to switch for usability. However, to implement core functionalities such as - Diagnosis, Registering custom symbols, jump to definition, etc a Language Server structure has to be adopted. For example, the client (say vs code) will communicate the godot language server to give desired result.
Microsoft's Language Server Protocol (LSP) is flexible and powerful to implement these functionalities. It also supports many editors - VS Code, Atom, Sublime, etc. Hence, instead of writing complete extensions for each editor (client) using LSP servers can be reused while the client which is an editor extension has to be only re-written.
I had a wonderful time coding with the fantastic and helpful community at Godot. I am mentored by jason0214 and geequlim, jason0214 is very responsible as he always points out my flaws and potential weekness from the regular code review. geequlim is very active to the project and I always get to learn a lot from his commits. Besides that it's an amazing experience to talk to other students and share whatever we learned. Writing clear and well structured code to meet standards, and making sure your changes does not break anything else was a truly educational experience.
I have the freedom to arrange my time and set my own plan, there's no pressure at all. Mentors encorage me to be as creative as I can and I'm free to choose how to finish my work. Summing it all up working at Godot has been a really great experience for me.
During this 3 months period, I along with my mentors were able to complete the LSP implementation in VS Code. The LSP Specification is based on an extended version of JSON RPC which can be basically used for sending notifications, requests and responses. For example: VSCode (Client) will first send a notification that the opened file is GDScript by matching it's extension then the Language Server will be connected. Client then again sends a notification defining what all capabilities it can provide. Rest most of the tasks can be broken down into request-response structure, client requests something server responds with a result.
Currently following features have been successfully implemented:
An Extended GDScript Parser is created inheriting from the original GDScript Parser with aim to carry specialized parsing task for LSP. Everytime there's a change detected by the LSP Server from client and diagnostics are updated i.e. Errors and warnings along with their relevant informations such as Range (line and column number for both start and end) and message are stored in a map for faster lookups.
Existing complete_code implementation from built-in code editor is reused however godot also matches written code continuiusly to filter out while in LSP at the beginning complete list of all items is sent to client by the server. Which then internally handles matching part, infact client's handles it better then builtin editor. In the below example writing 'texture' in LSP editor matches not only initial characters but also present anywhere within the item.
To provide lookup functionalities such as - Function Assist, Hover Provider, Symbol Resolve and Go to definition a symbol pool to cache all of the symbols (both native and script symbols) The cache pool is filled at the startup by parsing all scripts in the workspace for script symbols and loading native symbols from DocData.
To provide quick lookup at a class documentation, entire Godot docs is converted and dumped into system files which will can be directly opened by the editors. A simple Regex parser is capable of parsing the class name on 'View Symbol Documentation' incase parsed symbol isn't recognised list of all the symbols will be shown.
Support for direct access using ctrl + click or cmd + click to documents within GDScript, relative paths are also supported.
Majority of my task within final month revolved around testing the framework on larger open source GDScript projects. Bugs are regularly being tracked at (https://github.com/ankitpriyarup/godot/issues). During this time following bugs/improvements were traced and fixed:
- Better doc item indexing which parses entire class structure and stores it on a index.json file within markdown documentation directory for faster lookups.
- Hyperlink support in markdown docs such that by clicking on any link (Class or Method name) within the doc it will simply open that class or method.
- Visual improvements in markdown doc such as better spacing, indentation & paragraph shifts. Support for bold, italic and underline.
- Autocompletion for some methods also had an issue with it's insert text bracket placement which has been now resolved.
Most of the task has been done however, I was trying to also implement Rename symbol functionality, it first finds out the position of symbol definition and then the code replaces previous name to newly specified name from the position of definition till it's scope (by checking the indentation).
It had a huge drawback i.e. it is incapable of renaming symbols found within different classes searching and replacing it won't be an efficient solution. GDScript is a dynamic typed language so it is hard to track references for symbols. One possible way to do it could be to build a node tree and figure out the external reference between nodes. So instead of creating external symbols in symbol pool, we can just dispatch a rename into other GDScriptTextDocument. This approach will be way better and flexible then iteratively searching over for all possible references.
Progress on rename symbol functionality can be tracked from here (ankitpriyarup/godot#5)
Other important task that's left is to port it to more popular editors like Atom and Emacs, because of the flexibility of LSP it will be easier to port it to other editors and also while implementing extension for vscode we made sure to make Client smaller such that it will be easier to port it later on as well as to reuse existing implementation of built-in GDScript editor and reduce duplicacy.
I'm looking forward to contribute and work upon things that I missed post-GSoC and also encourage others who wish to contribute to this part of codebase.
Summers 2019 were definitely very pleasant and enjoyable for me. I am thankful to Google for organising such a great program that introduced me to FOSS world and increased my knowledge manifold. A big thanks to my mentors Geequlim & Jiacheng Lu for letting me become a part of Godot, and for helping me in improving not only our packages but also myself as a developer. And lastly thanks to all FOSS communities for helping each other and for letting novice developers like me, escalate their skills by working on their cool projects!
Signing off with 💓 to Open Source!