Currently two (at least) issues are appearing when there is a jpm_tree containing local files:

1. Some on-hover documentation points toward the jpm_tree, especially module imports (even when the module is not being imported from jpm_tree)
2. When (import)ing, any symbol inserted will be accepted as valid, even when that module does not exist; any modules contained in jpm_tree will then be suggested by autocompletion namespaced under that symbol
   • (This seems to be happening on each keystroke, meaning that if (import random) is typed, r, ra, ran, rand, etc. are all evaluated)

Probably has something to do with the way modules are being identified in jpm_tree---more experimentation needed.

I thought I'd try hooking up janet-lsp to a helix modified to work with Janet.

I'm not confident that the modifications were appropriate, but supposing they were for the moment...

Upon opening a .janet file in a custom-built hx, I quickly see the message:

Language server exited

near the bottom of the editor.

Apparently :log-open can show a log for helix and doing that revealed:

2023-10-11T21:18:26.183 helix_lsp::transport [ERROR] janet-lsp err <- "error: bad slot #1, expected string, symbol, keyword or buffer, got <tuple 0x556D94197080>\n"
2023-10-11T21:18:26.183 helix_lsp::transport [ERROR] janet-lsp err <- "  in peg/match [src/core/peg.c] on line 1701\n"
2023-10-11T21:18:26.183 helix_lsp::transport [ERROR] janet-lsp err <- "  in posix/dirname [/home/user/.local/lib/janet/spork/path.janet] on line 150, column 1\n"
2023-10-11T21:18:26.183 helix_lsp::transport [ERROR] janet-lsp err <- "  in find-unique-paths [src/main.janet] on line 186, column 20\n"
2023-10-11T21:18:26.183 helix_lsp::transport [ERROR] janet-lsp err <- "  in main [src/main.janet] on line 205, column 14\n"
2023-10-11T21:18:26.185 helix_lsp [ERROR] failed to initialize language server: server closed the stream
2023-10-11T21:18:26.185 helix_lsp::transport [ERROR] janet-lsp err: <- StreamClosed

I think I'll try to modify janet-lsp to try to ascertain some of the values that are flowing along.

I have a setup where my Janet deps live in a user-local folder, allowing the user to specify things like the $JANET_LIBPATH, $JANET_PATH, $JANET_PROFILE, $JANET_HEADERPATH etc. would allow users to use their custom environments.

As currently written, Janet LSP is not error tolerant—that is, the first error encountered is returned and the rest of the file is not evaluated. A better architecture would allow for multiple errors to be encountered and reported.

In some cases, errors are related to one another, such as an issue with importing a module preventing functions that use that module's symbols to evaluate either).

In other cases, such as ambiguous or undefined references, arity mismatches, or other compiler errors, the errors are completely independent.

Janet LSP should be able to report multiple errors, especially ones that are unrelated to one another.

Result of nil getting passed somewhere in sexp-at.

Janet LSP should be able to respond to Signature Help Requests from LSP clients.

This would involve, at minimum:

• Adding a :signatureHelpProvider key to the :capabilities map in src/main.janet
• Adding a "textDocument/signatureHelp" case to handle-message in src/main.janet
• Adding a on-signature-help top level function in src/main.janet
• Implementing signature help logic (possibly in a new .janet file in the src directory)

Presently, Janet LSP flychecks the user's code as received from the LSP client in the same environment that the server itself is running in. This creates opportunities for symbol collision and other glitchy behavior.

A better architecture would have user code evaluated in a separate environment table—either by specially-constructing an environment table in eval.janet to be passed to eval-buffer and its run-context call, or by running the functions in eval.janet in a totally separate fiber from the server process itself.

More testing and experimentation needed here.

At the moment, a module import such as (import spork/json) causes an error on Windows. This seems to happen with all module imports that are not project local.

It seems that 678b1a5 clears the initialization done in startup.janet, or something like that.

Learn from the excellent design of Textual's devtools: https://textual.textualize.io/guide/devtools/

Essentially, on startup have Janet LSP check for the presence of a debug console on a standard (or command-line argument parameterized?) port. If one is found, connect and route debug messages to it.