- Briefly outlines the proposal
- Suggests a review team (optional)
- Declares why it should be a JEP (See the “JEP / Not-a-JEP Rubric” below.)
- Identify a Shepherd to see the process through. (Shepherds are assigned on a round-robin basis from a set of interested engaged volunteers).
- Decide if it’s a JEP according to the criteria listed above. The Shepherd decides if the JEP criteria have been met.
The maintainers of the jupyter(lab)-lsp would like to propose its incorporation as an official Project Jupyter project, as signalled by a new, Jupyter-branded GitHub organization. We feel it would benefit Jupyter users through higher velocity in delivering more robust features otherwise missing in the Jupyter interactive computing experience.
The key component of the repository, @krassowski/jupyterlab-lsp, offers Jupyter users a limited subset of features described by the Language Server Protocol (LSP) as an extension to JupyterLab. These features include refinements of existing Jupyter interactive computing features, such as completion and introspection, as well as new Jupyter features such as linting, reference linking, and symbol renaming. It is supported by jupyter-lsp, a Language Server- and Jupyter Client-agnostic extension of the Jupyter Notebook Server. We will discuss the architecture and engineering process of maintaining these components at greater length, leveraging a good deal of the user and developer documentation.
Much like Jupyter Kernel Messaging, LSP provides a language-agnostic, JSON-compatible description for multiple clients to integrate with any number of language implementations. Unlike Kernel Messaging, the focus is on precise definition of the many facets of static analysis and code transformation, with nearly four times the number of messages of the Jupyter specification. We will discuss the opportunities and challenges of this complexity on users and maintainers of Jupyter Clients and Kernels.