Inline evaluation result never disappears.

[migraine-user]

It seems to work as intended initially:

However, when you insert a newline afterwards, this happens:

Then when you insert a new expression like such:

and evaluate it, it works as normal like such:

However, it's possible to do something like this:

I'm genuinely confused as to why this one happens, this happened when I evaluated a different s-expression below:

This makes the inline evaluation a bit difficult to use. In Calva, a similar extension for clojure, I believe it has these behaviors:

• when a newline appears, the evaluation stays in the same line
• when editing within an evaluated s-expression, the inline result becomes invisible.
  I believe this could be a good way to implement inline evaluation for this extension as well!

[Release-Candidate]

Thanks again for your report. Without irony, I really appreciate that somebody is using my program and it doesn't matter that this is a bug report.

First, the main idea of my evaluated values is that they are persistent, so they don't disappear when changing windows or evaluating more than one expression.
But that is too much sometimes, so I've just added a command to remove all such evaluation results from the view - Chez Scheme REPL: Remove all evaluated values from the view. (chezScheme.removeEvalVals). This version is not yet released, but you can use that as a workaround until the newline-handling is fixed.

Why there are more than one such evaluated value after each newline: that's because I have used the range from the start of the expression up to, and including, the cursor position as the range of the result - so they all differ by the end of the range and are treated as different. I've just changed that: comparing the start line is enough and it works as expected now.

Why the evaluation result is shoved into the next line is a bit of a mystery to me, if you select another window and go back to the original tab the text decoration is on the right line again. So regenerating all such text decorations would work, but I'd rather evade doing that on each keypress. So I'm searching for a better solution.

[Release-Candidate]

Thinking through the possibilities, I actually do have to remove at least all eval results after the location of the newline, as all these are one line to high after redrawing them.
So I guess I'll just remove all of them as soon as the view has been edited.

[migraine-user]

Thank you for the wonderful extension. I'm new to OSS in general. If it's alright with you, I have found some other errors.

Even after changing tabs, the evaluation result from a deleted s-expression is still present.
Also, when I evaluate individual s-expressions in a line and contained in one s-expression, only one of them can be evaluated/visible at a time. When I evaluate another, the other disappears.
It works as expected when you separate the s-expression into multiple lines:

And when the expressions aren't nested with each other (the nested s-expression issue is still present):

I was able to recreate the last error I mentioned in the original issue a couple times, but I could not figure out how to recreate it.

If it's okay with you, would it be possible to have an option to evaluate the expressions in the repl window? It would make the extension very useful immediately.

[Release-Candidate]

If it's okay with you, would it be possible to have an option to evaluate the expressions in the repl window? It would make the extension very useful immediately.

<Ctrl>-<Shift>-<Return> should send the expression to the left to the REPL, it's also in the right-click-menu. But you have to send the whole file with an extra command, "Send the whole current file to the REPL", it isn't done automatically like with the inline evaluation. If this is what you were talking about. If not, please elaborate.

Actually the nested expressions - the last image - had been intentionally, but with the latest change (which isn't checked in) this doesn't happen any more, there is always only one eval result per line.

[Release-Candidate]

I've just published a new version - 0.7.0. Please check if this is working as you would expect.

[migraine-user]

The inline evaluation of the built-in functions work as expected!
However, I have a couple other errors, still.

It seems as though inline evaluation is running in a separate context from the repl window. What is odd to me is that even after defining add by evaluating inline, it says that it is unbound. It might just be my lack of understanding of chez scheme though.

An indent is inserted after the define block, when I would expect there wouldn't be:

[Release-Candidate]

It seems as though inline evaluation is running in a separate context from the repl window.

Yes, these are 2 different REPLs. The problem is that I can't get the output of the terminal the interactive REPL is running in.

What is odd to me is that even after defining add by evaluating inline, it says that it is unbound.

Oh, yes. I should have documented that, both REPLs (inline vs. interactive) behave totally different.
What the inline evaluation does is send the contents of the file and afterwards the selected s-exp or s-exp to the left of the cursor to a Chez REPL, which is closed afterwards. So instead of evaluating the function definition you would have to save the file and then evaluate (add 1). I did that because I got tired of always having to manually evaluate the definition(s) first. And by loading the whole file all imported libraries are useable too. And by saving the file it is checked for errors and the auto-completion is updated, so add is known after saving the definition of add.

An indent is inserted after the define block, when I would expect there wouldn't be:

Oh, yes. Sadly these indention rules use regexps, so there is no way to let VS Code know that the define expression is already finished. But I thought most of the time definitions use more than one line, so not adding additional indentation would do more harm that adding it. These are the onEnterRules in the language configuration file language-configuration.json, I don't know if a user can override these, if necessary.

[Release-Candidate]

I'll add some kind of popup asking the user to save the changes, if the file hasn't been saved before evaluating some expression inline.

[Release-Candidate]

I've just published a new version, this added the popup on unsaved changed when inline evaluating.

[migraine-user]

It works perfectly now! Thank you so much.

[migraine-user]

Yes, these are 2 different REPLs. The problem is that I can't get the output of the terminal the interactive REPL is running in.
This must be why calva creates an active text editor window for the repl that parrots the output from running the repl, so the text can be read from the extension side. I would think a similar path can be taken for this project as well.

[Release-Candidate]

You're welcome! You have been a great help in fixing these bugs and making the extension better. Most open source projects (well, these projects are most often made by a single person) like having bug reports even if they not respond quickly. Because almost anybody likes seeing their work used and people care enough to go through the hassle of reporting bugs and helping with their resolution.

What Calva does is not using a REPL directly, but connecting via TCP. This started with Emacs and Common Lisp, where the REPL is wrapped in a TCP server (a "swank" server, which Slime and Sly use), so the communication is way "better" than by using pipes to communicate with a running REPL. The LSP servers of VS Code use the same principle, but another protocol. Btw. this had been the reason I started with this extension, as the scheme-lsp-server has a working VS Code plugin, but does not support Chez. And scheme-langserver, which does support Chez, doesn't have a VS Code plugin and I couldn't even compile the LSP to write the VS Code LSP client for it.

[migraine-user]

I'll add some kind of popup asking the user to save the changes, if the file hasn't been saved before evaluating some expression inline.

This popup shows up not only on eval, but also when just writing code. Would it be possible to pop up only on inline evaluation without saving?

[Release-Candidate]

Oh, of course, autocompletion is also evaluating code. I should ignore that.

[Release-Candidate]

The newest version, 0.7.2, fixes that. Sorry I didn't catch that error 😢

[migraine-user]

The newest version, 0.7.2, fixes that. Sorry I didn't catch that error 😢

No problem! It's very useful for me now :)