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

Print full evaluation error to output window #2030

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

julienvincent
Copy link
Contributor

This is a PoC to demonstrate the REPL output behaviour I would like to see when editor evaluations throw errors. This is to address #2029 - please read that issue first to get a better idea of the problem this is trying to solve.

This is just a draft to show what I would like and to open the discussion on how we want this to work in practice. I'm sure people will have a lot of differing opinions on this one - probably requiring some calva configuration to control the behaviour.

This change will result in evaluation errors looking as follows:

Simple error:
Screenshot 2023-01-23 at 12 19 03

More complex error with additional data:
Screenshot 2023-01-23 at 12 18 32

This addresses the three main points of the issue raised:

  • It is immediately easier to parse as a result of the syntax highlighting. My eye is drawn to the right pieces of information and is structured such that I don't need to scroll the window horizontally to read the full error.
  • It contains the full stacktrace without needing to click to see it. For me, this is always the behaviour I want
  • It does not omit important information needed to resolve the issue. For the second image, this would be the :data key.

This implementation is quite primitive - I would guess some errors also contain other information besides :data that would need to be printed. This would need to be taken into account for a real implementation.


Checklist

  • Read How to Contribute.
  • Directed this pull request at the dev branch. (Or have specific reasons to target some other branch.)
  • Made sure I have changed the PR base branch, so that it is not published. (Sorry for the nagging.)
  • Updated the [Unreleased] entry in CHANGELOG.md, linking the issue(s) that the PR is addressing.
  • Figured if anything about the fix warrants tests on Mac/Linux/Windows/Remote/Whatever, and either tested it there if so, or mentioned it in the PR.
  • Added to or updated docs in this branch, if appropriate
  • Tests
    • Tested the particular change
    • Figured if the change might have some side effects and tested those as well.
    • Smoke tested the extension as such.
    • Tested the VSIX built from the PR (so, after you've submitted the PR). You'll find the artifacts by clicking Show all checks in the CI section of the PR page, and then Details on the ci/circleci: build test.
  • Referenced the issue I am fixing/addressing in a commit message for the pull request.
    • If I am fixing the issue, I have used GitHub's fixes/closes syntax
    • If I am fixing just part of the issue, I have just referenced it w/o any of the "fixes” keywords.
  • Created the issue I am fixing/addressing, if it was not present.
  • Formatted all JavaScript and TypeScript code that was changed. (use the prettier extension or run npm run prettier-format)
  • Confirmed that there are no linter warnings or errors (use the eslint extension, run npm run eslint before creating your PR, or run npm run eslint-watch to eslint as you go).

Ping @PEZ, @bpringe, @corasaurus-hex, @Cyrik

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

Successfully merging this pull request may close these issues.

None yet

1 participant