The following macros from the core API currently indent like normal tuples rather than like do:

• compwhen
• coro
• defer
• edefer
• ev/do-thread
• ev/spawn
• ev/span-thread
• ev/with-deadline
• ffi/defbind
• fiber-fn
• forever
• for
• forv
• generate
• label
• prompt
• protect
• repeat
• when-with
• with

Currently, having ; anywhere in a form causes the autoformatter to choke.

Looks like ; is not handled in parser/core.cljs—look at

Will probably need a new node type added as well (Clojure doesn't have an equivalent to splice)

Currently will re-format Janet's anonymous function macro, which should look like this:

|(fn args)

to this instead:

| (fn args

Fortunately doesn't cause anonymous function to break (Janet ignores the whitespace) but should still fix.

Probably as simple as adding | to a regex somewhere that handles prefixes (like # or @ in other places).

Right now, the best/only way to reboot the LSP is to refresh the entire editor window, which is not best.

Currently the lexer recognizes only "regular" (short?) strings (i.e., those wrapped with " regular quotation marks). Janet supports long strings, which currently is not recognized by the lexer.

This causes the janet:cursorInString flag to be false even when the cursor is inside of a long string.

This causes structural editing features to misbehave when the cursor is inside a long string.

Also, auto indentation inside long strings is unpredictable.

I added a new module to my local code during a session. Janet++ told me the imported bindings didn't exist. Restarting VS Code fixed the problem.

I'm using the v.1.1.2 prerelease.

feature request
You should have the possibility to set the path in the plugins settings to your own language server version. Default should be the language server, which is delivered with the extension.

Maybe the user can also set an environment variable to the path of the language server in his operating system. If this is set, this can also be selected as default.

It is important that the extension handles the path differently in operating systems like linux or windows.

OS: Linux Mint 21 x86_64

I'm using VS Codium instead of VS Code.
Version: 1.72.0

Currently, Ctrl + Arrow key invokes Janet Paredit: Move Cursor [Forward | Backward or Up] Sexp/Form (aka janet.paredit.backwardSexp). That's good in code, but really annoying in a comment (where it would be better to only do cursorWordLeft/cursorWordRight).

I'm attempting to use Janet++ in a small project and see this error when the LSP attempts to start:

error: nil called with 2 arguments, possibly expected 1
  in <anonymous> [src/main.janet] on line 212, column 13
  in map [boot.janet] on line 998, column 3
  in find-unique-paths [src/main.janet] on line 212, column 8
  in main [src/main.janet] (tailcall) on line 228, column 14
  in run-main [boot.janet] on line 3936, column 16
  in cli-main [boot.janet] on line 4076, column 13

I'm running Janet 1.32.1-meson on Mac OS and VSCode 1.83.1

For instance, I have a local variable called retry. When I write the name of the variable and press enter, it's auto-expanded to render-texture-ready? from jaylib. Top-level bindings don't seem to have this problem.

Caused by removing the "raw" flag from janet invocation because not being able to use arrow keys in the REPL was bugging me so much. But now it's caused this new annoying issue.

Create a new Janet file. Type a top-level def- binding. Start typing the bound identifier. Incomplete versions of the name appear in the completion list. For instance, if the identifier is circumference, completion will suggest ci, cir, circ, circu, etc.

Hi,

when i import the janet json module i get the following error.
(import json :prefix "")

"could not load native /usr/local/lib/janet/json.so: config mismatch - host 1.31.0(0001) vs. module 1.32.1(0001)".

i reinstalled janet 1.32.1, recompiled json, changed the language server etc.
which config is meant? or where does this error come from?
System:
Distributor ID: Ubuntu
release: 22.04

thanks, Felix

The "evaluate expression" command in Janet++ has a few peculiarities compared with pretty much every other evaluate-in-editor plugin I've used:

1. Evaluating an expression also selects the expression for some reason.
2. The command doesn't really evaluate expressions; it evaluates top-level forms. If it's supposed to be "evaluate expression", you should be able to put the cursor after a subform or literal or whatever and evaluate just that.
3. Top-level forms that aren't enclosed in parens/brackets/etc. can't be evaluated (it looks like just a newline is sent to the REPL).

I'm using v1.1.1 pre-release. Thanks for this project; I was really pleased to see that someone was working on this sort of thing.