Develop proposal for language server-based editing in existing code editors.

[cproctor]

Last meeting we discussed the idea of implementing support more robustly via a language server. This seems like a great idea: the specification for codes is very simple, and this is exactly the use case for which LSP was developed (providing unified support to a bunch of different code-editing tools). Here are a few resources I read as I researched this proposal:

• langserver.org
• A writeup of implementing a language server
• pygls, a python library for language servers

The next step is to specify how this would work and to bound the scope of work:

• What will be involved in packaging the language server as a plugin for various editors? Let's consider vim, emacs, and vscode for now.
• Which language do you propose writing the language server in? Currently, qc is implemented in python, so there's some attraction to also implementing the server in python (makes packaging and distribution easier?) But I could be open to node (fundamentally async; vscode is in node), go (existing proposal to reimplement qc in go), or another language.
• Please sketch the proposed sequence diagrams between the client and the language server.
• Can you think of issues we haven't considered, which could be blocking?

[cproctor]

As we discussed last week, the LSP is a nice-to-have, bu not included in the paper submission milestone.

[cproctor]

I'm not closely familiar with what's possible with a language server, but it would be lovely if we could have an autocomplete mode which allowed the user to traverse the code hierarchy. For example, if we have the following codebook:

- rq1_definition:
  - competencies:
    - programming

then typing rq1 would autocomplete to rq1_definition, an additional tab press would drill down to rq1_definition:competencies, and a third tab press would again drill down to rq1_definition:competencies:programming. If this were selected, only programming would be inserted into the codes file.

[cproctor]

Adding a random thought here: Once we have a embedding-based estimation of code clusters, we could implement a LSP-based suggestion tool. Especially if the code clusters updated dynamically, this could be an extremely efficient way of doing qualitative coding.