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

cider-log: multiline items #3612

Open
vemv opened this issue Jan 23, 2024 · 5 comments
Open

cider-log: multiline items #3612

vemv opened this issue Jan 23, 2024 · 5 comments

Comments

@vemv
Copy link
Member

vemv commented Jan 23, 2024

I encountered this one today:

2024-01-23 19:30:31.000 [qtp1494871543-1108] ERROR foo.bar.baz - ERROR: operator does not exist: uuid = character varying
  Hint: No operator matches the given name and argument types. You might need to add explicit type casts.
  Position: 57

It's rendered as 3 lines, in red.

It seems no big deal, but perhaps we'd like to render these as a single line? Would be more compact. One can always inspect the context or stacktrace in detail, anyway.

Thoughts? @r0man

@r0man
Copy link
Contributor

r0man commented Jan 24, 2024

Hi @vemv,
I think this can also happen when stacktraces are printed. I don't have strong opinions and I'm fine with rendering it on a single line. We also truncate long messages to not bring Emacs down, with the idea that you can inspect them if you really want to.

@vemv
Copy link
Member Author

vemv commented Jan 29, 2024

Thanks!

Good idea on truncating. We could have options if anyone wanted to opt out.

I've noticed that the newlnes may be our fault sometimes:

image

that output can reproduced with a simple (c.t.l/error :foo (ex-info "a" {})).

Maybe we could be using pr-str / str better somewhere in Logjam, idk.

@r0man
Copy link
Contributor

r0man commented Jan 30, 2024

@vemv I don't follow, what do you mean by "I've noticed that the newlines may be our fault sometimes".

Another idea that came to my mind is: Maybe it's actually nice to see the printed exception sometimes, or the "thing" that spans multiple lines. By default we could show only the single/first line, but if the user presses a key (maybe TAB), the log line would expand and show on multiple lines. That key can be a toggle, you press it again and it goes back to a single line. This could be useful if you are fishing for something in the logs.

Exceptions are probably better viewed in the stacktrace inspector, but for long strings that could be useful. I think you can also jump into the inspector and view long strings there. I believe I changed them to also be printed on multiple lines.

@vemv
Copy link
Member Author

vemv commented Feb 1, 2024

@vemv I don't follow, what do you mean by "I've noticed that the newlines may be our fault sometimes".

I meant, maybe somewhere in logjam we use pr-str instead of str for exceptions.

But I was probably wrong in saying that, the pr-str or str is not performed by logjam, but by either the logging library or the user application.

. By default we could show only the single/first line, but if the user presses a key (maybe TAB), the log line would expand and show on multiple lines.

This would sgtm! Assuming it would be reasonably cheap and would not compromise anything.

I believe I changed them to also be printed on multiple lines.

Yes, correct, that would be good reasoning for trimming the lines, guilt-free :)


One last consideration: if we are to remove newlines, we shouldn't just remove the newlines, but also truncate everything after the first newline.

The reason is that long lines are known to cause Emacs slowness.

@r0man
Copy link
Contributor

r0man commented Feb 3, 2024

Thanks for the clarification. Yes, truncating according to cider-log-max-message-length seems fine.

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