the 'get_server_document' command, and it's protocol allows the client to request a derived document about a parser/parse.
E.g. it will derive from a parser into a railroad diagram, from a parse tree into a generictree ast.
These are always converted based on the LSP's current grammar. Once the underlying grammar changes, the rendered derived document will not update. Just a static snapshot of the current state when the client requests it.
a few limitations worth considering:
We don't store deltas of the underlying grammar/input anywhere, which means we can't create a comparison between different versions of the grammar.
We have no mechanism for updating or watching the input to a derived document and updating it when the input changes.
The current behavior binds a key binding, different keybinds tend to work with a specific focused document. If the wrong type of file e.g. if you have a grammar focused the generic tree doesn't do anything, if you have a input file open, the railroad diagram doesn't do anything. There may be for instance a mechanism to enable/disable commands which are/aren't applicable to the current document greying the menu item out, or producing an error if you attempt to run a command for the wrong type of document.
the 'get_server_document' command, and it's protocol allows the client to request a derived document about a parser/parse. E.g. it will derive from a parser into a
railroad diagram
, from a parse tree into agenerictree ast
.These are always converted based on the LSP's current grammar. Once the underlying grammar changes, the rendered derived document will not update. Just a static snapshot of the current state when the client requests it.
a few limitations worth considering: