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

Navigable inspected exceptions #227

Open
vemv opened this issue Feb 25, 2024 · 4 comments
Open

Navigable inspected exceptions #227

vemv opened this issue Feb 25, 2024 · 4 comments

Comments

@vemv
Copy link
Member

vemv commented Feb 25, 2024

Currently, if we're inspecting an Exception, we cannot directly navigate to the file/line of each element of the rendered stacktrace.

i.e., this stacktrace is just text atm:

image

Currently, a workaround is to d (cider-inspector-def-current-val) the inspected Exception, and then throw it in the repl. cider-stacktrace-analyze-in-region may also work.

I think that something very "inspector-like" would be to reify the stacktrace into something that also is navigable:

  • navigable cause chain
  • individual stacktraceelements rendered similarly to members of a vector
  • a keybinding / click action to open stacktraceelements as clojure buffer
@vemv
Copy link
Member Author

vemv commented Apr 30, 2024

@alexander-yakushev a possibly easy subset of this problem is making sure that stacktraces have a reasonable length limit by default.

At the moment (cider-nrepl latest stable) they can create a huge line, slowing down Emacs.

Perhaps it's already fixed (or easy to configure) given the latest additions?

@alexander-yakushev
Copy link
Member

alexander-yakushev commented Apr 30, 2024

We can provide a custom print function for Exceptions that limits the length, or I suggest setting inspector's default newly introduced max-value-limit to something reasonable, 5000 or 10000 (my (* (window-width) (window-height)) is 6000). This will take care of exceptions and any other values that render into something huge and don't honor *print-length*.

@vemv
Copy link
Member Author

vemv commented Apr 30, 2024

Thanks!

I'd go for the latter - seems a generalized fix for an area that could slow down Emacs (so it's reasonable to consider this broken already)


Not sure if max-value-limit can be passed from cider/cider-nrepl, that would be a nice follow-up addition.

@alexander-yakushev
Copy link
Member

Not sure if max-value-limit can be passed from cider/cider-nrepl, that would be a nice follow-up addition.

It will be, as new cider-nrepl ops, currently can be seen here: clojure-emacs/cider-nrepl#869.

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

No branches or pull requests

2 participants