@User got it. so instead of

plugin/cli -> engine -> lsp

, you're proposing

plugin/cli -> lsp -> core

. in this case,

lsp

would basically serve as an

api gateway

of sorts, abstracting the implementation details of the engine behind the lsp > To get the lookup results into extension, I believe server extension communication can be extended with custom JSON RPC messages (thus: extension asks completion -> server asks it from core -> core constructs that from its index, returns to server -> server returns result to extension) this is where I need to get more clarity on. wasn't obvious whether LSP supported custom messages or if we had to overload one of the existing functionalities > - IIRC, file watching is done by the VS Code, and it will notify the LSP server whenever any file relevant for the extension is changed. Typically every change would cause index refresh + sending status + diagnostics from server to extension (probably with some throttling). i'm up in the air about this. if we want the lsp/core to be vscode independent, it would be easier to delegate file watching to the server. plus it'll use the vscode fs watcher interface present day so functionally, wouldn't be a big change either way. are there advantages for doing file watching inside vscode isntead? > - Things like creating daily notes, I would delegate via extension -> core, so that CLI can then do similar thing via CLI -> core (thus logic for it would only reside in core) i like this. core would continue to index, lsp is just the messaging layer that helps decouple the engine/core from its js implementation.