Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues with "evaluate expression" behavior #16

Open
jangler opened this issue Jan 9, 2024 · 4 comments
Open

Issues with "evaluate expression" behavior #16

jangler opened this issue Jan 9, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@jangler
Copy link

jangler commented Jan 9, 2024

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.

@CFiggers
Copy link
Owner

CFiggers commented Jan 9, 2024

Hey thanks for the feedback!

Janet++ began life in private as a personal fork of the "official" Janet VS Code extension. The "Evaluate expression" command isn't something I've ever paid close attention to, since from day one (i.e., the day I started using vscode-janet) that part has "worked ok," more-or-less. All three behaviors you describe come from the implementation of Evaluate expression in that original version. But, I think you're right on all three points—the current behavior is not ideal and should be improved.

In the mean time, there is a work-around for evaluating specific forms, including top-level ones that are not enclosed in parens/brackets, and that is to manually highlight/select the form that you want to eval before triggering the eval command. This should work both for nested sub-expressions and top-level ones outside of brackets, and with the select-by-S-expr behavior of Ctrl+Shift+<R/L Arrow> in Janet++, it hopefully isn't inordinately annoying.

But I will try to bring expression eval in Janet++ more into line with Calva, which will likely address all three of your points. For instance, in the future we will probably have two separate commands, one for eval'ing top-level forms and one for eval'ing current form/selection only.

@CFiggers CFiggers self-assigned this Jan 9, 2024
@CFiggers CFiggers added the enhancement New feature or request label Jan 9, 2024
@jangler
Copy link
Author

jangler commented Jan 9, 2024

Got it. Bringing it in line with Calva would be great. For now, knowing the workaround is helpful. Thanks!

@CFiggers
Copy link
Owner

Old and busted:

janet++evalbefore_2024-01-28

New hotness:

janet++evalafter_2024-01-28

(Coming soon)

@CFiggers
Copy link
Owner

"Soon" turned out to be seven months later... But this is now shipped in v1.1.6 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants