Multiline values

[ansel1]

When an attr value has newlines in it, it can make the value of the attr a little hard to scan. For example, in the below output, consider the "errorVerbose" attribute. The value of this attribute is:

boom

main.testVariousHandlers
        /Users/regan/dev/flume/v2/cmd/demo/main.go:215
main.main
        /Users/regan/dev/flume/v2/cmd/demo/main.go:78
runtime.main
        /opt/homebrew/Cellar/go/1.23.4/libexec/src/runtime/proc.go:272
runtime.goexit
        /opt/homebrew/Cellar/go/1.23.4/libexec/src/runtime/asm_arm64.s:1223

It's a little hard to scan, because the first line of the value ("boom") appears on the same line as the key, and the last line of the value also includes the "size" attr.

I have some sample code which sorts all multi line values to the end of the buffer, so simple values are all on a single line together, and then the multi-line values are each printed on their own line. Note how the key and the value each have their own line. I also used a different separator for them (":" instead of "="), just as an experiment. Would you consider a PR for something like this?

[phsym]

Hi ! That's an interresting proposal for which I would definitely consider a PR 🙂

[ansel1]

I am working on another PR which merges the other PRs together. They were all playing in the same files, and could each take advantage of some of the optimizations in the others.

I've optimized them such that there are still zero allocations, even when all the features are in use. The only feature which adds some overhead is the multiline handling. In my local benchmarks, that increases the duration of Handle() from around 750ns to 900ns. The others have no performance impact (in fact, its a little faster than before).

I'm just crossing some t's and dotting some i's on that. Should have it submitted today. Put the other PRs in draft for now.

[ansel1]

Just pushed a new PR with these features merged together. #15