cider icon indicating copy to clipboard operation
cider copied to clipboard

cider-log: multiline items

Open vemv opened this issue 7 months ago • 5 comments

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

vemv avatar Jan 23 '24 18:01 vemv

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.

r0man avatar Jan 24 '24 18:01 r0man

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.

vemv avatar Jan 29 '24 20:01 vemv

@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.

r0man avatar Jan 30 '24 08:01 r0man

@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.

vemv avatar Feb 01 '24 20:02 vemv

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

r0man avatar Feb 03 '24 09:02 r0man