Remove brackets and message field name from rendered message

[oli-obk]

I found some other code that was also matching on the message name and skipped printing it. I extended it to the code here, but I was unable to figure out how the other code is invoked or how to trigger it, since it looks to me like it would render "foo" instead of foo, because it's using Debug printing which renders quotes around strings.

Here's a rendered version:

As text:

1:main│ ├┐basic::server host="localhost", port=8080
1:main│ │└┐basic::foomp 42 <- format string, normal_var=43
1:main│ │ ├─0ms ERROR basic hello
1:main│ │┌┘basic::foomp 42 <- format string, normal_var=43
1:main│ ├┘basic::server host="localhost", port=8080

fixes #18

[davidbarsky]

Few notes:

• I don't think there's much that we can do about "foo" being rendered instead of foo. That might need to be fixed in tokio-rs/tracing's macros.
• I think that removing {message="..."} is unambigously the right choice.
• I'm a fan of {} being dropped from non-message fields. I'd like to keep that and introduce a toggle.

Speaking of toggles, how do you feel about not merging this PR and instead exposing some pre-configured event and field formatters from tracing_subscriber::fmt? It might reduce some of the complexity in this crate. That said, if this change unblocks rust-lang/rust#75143 (comment), I'll be happy to merge this and release it as 0.2.beta-1.

[oli-obk]

I tried figuring out the formatting infrastructure in tracing_subscriber::fmt for two hours and have not gotten much further with understanding the parts. I would indeed prefer to merge (potentially with more toggles).

* I'm a fan of `{}` being dropped from non-`message` fields. I'd like to keep that and introduce a toggle.

You mean "not a fan"? so the default should be to keep it?

* I think that removing `{message="..."}` is unambigously the right choice.

do we keep the {} around it without the flag from the non-message fields?

* I don't think there's much that we can do about `"foo"` being rendered instead of `foo`. That might need to be fixed in tokio-rs/tracing's macros.

this all works out great, we do get foo.

[davidbarsky]

I tried figuring out the formatting infrastructure in tracing_subscriber::fmt for two hours and have not gotten much further with understanding the parts. I would indeed prefer to merge (potentially with more toggles).

That's fair, their documentation and organization can be improved. Sorry to send you on a wild goose chase. I can make this a feature for 0.2.

You mean "not a fan"? so the default should be to keep it?
do we keep the {} around it without the flag from the non-message fields?

Sorry, that was confusing. Oncall's been busy, so I edited that poorly. I was trying to say that treating the message field as a special case such that {message="..."} is no longer rendered is the right choice. However, I'd like to have the current curly bracket treatment for all non-message fields available behind a toggle. How do you feel about that?

• I don't think there's much that we can do about "foo" being rendered instead of foo. That might need to be fixed in tokio-rs/tracing's macros.
  this all works out great, we do get foo.

Okay!

[oli-obk]

I updated the commit so the brackets can get enabled again if desired. We should probably merge the ui test PR before this so we can use it to review this PR 😆

[davidbarsky]

I updated the commit so the brackets can get enabled again if desired.

Thank you!

We should probably merge the ui test PR before this so we can use it to review this PR 😆

Eager to try it out in reviewing this PR! 😄

[oli-obk]

I set the stderr example to showcase that the with_bracketed_fields flag actually works properly (which immediately caught a bug 😆 )

[davidbarsky]

Sorry for forgetting about this! Looks good to me; we can fix this in subsequent PRs.