Come a long way with the /console/inspect. In fact, between restraml schemas+diff (using request=syntax & request=child), which has RAML and OpenAPI schemas, and an RouterOS LSP for syntax colors/errors/completion (using request=completion & request=highlight) — using most what /console/inspect has to offer.
While the LSP gets pretty far with inspect’s completion and highlight data. RouterOS LSP does gets limited since I have not been able to figure out, reliably, what the “current working directory” is when using any /console/inspect request=... input="some code" things. The LSP’s view of RouterOS script is only “highlight” tokens associated with text position in an LSP client editor (VSCode, nvim, etc). But Inspect’s tokenizer knows definitively the current path= (in the ip,address sense) since it resolve subshells like [find] and other syntax which inherent some path perfectly. While in some cases path could be inferred like /ip/address/add... where it’s “fully qualified”. This limited the possibility to a request=syntax in the LSP to offer editor the “signature” (i.e. CLI’s F1 help).
So if you had a new “easter eggs” for this cwd problem, be good to know. The full set of issues where /console/inspect is limited is here:
With the added question/mystery… /console/inspect request=error is one I not been able to figure out what it does. Any new clues? It’s always nil regardless of what is provided (both valid or all sorts of invalid syntax)
:put [:typeof [/console/inspect request=error input=":put [/system/identity/get name]"]]
# nil
:put [:typeof [/console/inspect request=error input="/somebadcommand"]]
# nil
But guessing it does something, just don’t know what. Right now it’s riddle in within in the easter egg inspection.