Disable message auto-quoting

[serddmitry]

Hello and thanks a lot for a very useful tool.

I've noticed that some log messages are quoted (some using double quotes, others - backticks). I understand that this behaviour is triggered by the presence of some characters in the message (equals sign for double quotes).

I'm looking for a way to disable this quoting, because some of my messages are quoted and others are not, I really don't care if there is some special character in the message.

Is it possible to configure this perhaps?

Thank you.

[serddmitry]

I've found the logic responsible for quoting in formatting.rs and I see that it's hardcoded. I would like to rephrase my question to whether you would consider making this customizable? Thanks!

            if !mask.intersects(Flag::EqualSign | Flag::Control | Flag::Backslash)
                && !matches!(buf[begin..], [b'"', ..] | [b'\'', ..] | [b'`', ..])
            {
                return Ok(());
            }

[pamburus]

Hello, thank you for your feedback.

Currently, the formatting logic is indeed hardcoded. The primary reason for this approach is to ensure messages can always be interpreted unambiguously, regardless of their content. However, I understand this sometimes leads to less visually appealing results. Ideally, messages should be as clean and readable as possible.

I'm generally open to making this behavior customizable, along with other aspects of the layout and formatting. I've considered various options, but the main challenge is balancing readability with unambiguous interpretation. For key/value fields, the decision to include quotes is relatively straightforward—typically, quotes aren't necessary unless the field contains control characters (0x00–0x1F), spaces, quotes, or equal signs. When quotes are required, we have three distinct quoting options to manage such cases.

However, formatting the primary message (msg) in a way that clearly distinguishes it from other fields presents a more significant challenge. One solution could be to provide detailed configuration options allowing fine-grained formatting control. Yet, this level of detail might introduce unnecessary complexity.

An alternative is to handle the msg field the same as any other key/value pair, similar to the approach taken in logfmt. With this method, most messages would require quotes due to spaces within them. This behavior can already be enabled by setting the list of message field names to []. However, in practice, I find this less readable.

I'm open to suggestions on how we might best handle this trade-off between readability and unambiguous interpretation. Which set of options would you like to have to control when and how messages are quoted or formatted in an alternative way?

[serddmitry]

I see your point. In my case, equals sign is quite often present in especially debug-level messages, as those message often include string representations of different objects (which often look like e.g. Person(id=5, name=Alex)). In our logs it is obvious that I'm still looking at the message itself, not on other fields. This is especially true since other fields are shown with a different color, so this is very clear that it's not part of message anymore.

I could see 2 approaches: one is to provide just a boolean setting to enable or disable quoting values with potentially ambiguous characters.

A more involved approach could be, for example, 2 list settings:

1. Characters that trigger quoting.
2. List of pairs of characters (opening, closing) to use for quoting.

The logic would be to try to use a pair of quotes, in order, if it is not present in the message. Otherwise – try next pair (last pair always applies even if its characters are present in the value). Defining a pair instead of a single element would allow nice typographic choices, like «…» or “…” instead of simple "".

Perhaps, if we use proper typographic quotes, we can be reasonably sure that they won’t be present in the message text, and just keep using a single pair of quotes without having to check if it occurs in the quotes value. Then a list of fal back quote pairs is not needed.

[pamburus]

This is especially true since other fields are shown with a different color, so this is very clear that it's not part of message anymore.

I intentionally avoided relying on color distinctions because it's quite common for users to copy text directly from a terminal, losing all color formatting. When colors are lost, ambiguity may arise, which would undermine readability.

Characters that trigger quoting

While defining specific characters to trigger quoting could be done, it would inevitably introduce ambiguity when colors are removed from the copied text.

List of pairs of characters (opening, closing) to use for quoting.

Customizing pairs of quotes is certainly possible, but I don't think it would resolve the core issue described here.

Perhaps using a consistent formatting approach for messages — such as enclosing them uniformly in distinctive quotes (e.g., «…») — rather than conditionally adding quotes, could enhance consistency and readability. If rarely used quotes were chosen, this could also significantly reduce the need for escaping special characters in most cases.

To clarify, is your primary concern that the current formatting feels inconsistent because some messages appear quoted and others do not?

[serddmitry]

In our logs, roughly 20% of message contain equals signs, and when I'm scanning the screen vertically along the edge of the line where all messages begin, it looks roughly like this for me:

Doing something Doing something else "Doing something with Person(name=Alex)" Doing yet another thing "Another action on a [Person(name=Alex), Person(name=Bob)]"

This jagged line introduced by quotes is not helping quick and easy visual scan along this vertical line. My only suggestion was to introduce any way to make it go away.

I understand your concern about ambiguity, however I'm not suggesting to remove quoting behaviour by default, just asking for an option to disable it.

[pamburus]

Ok, I see your point.

To address this, I propose introducing an option to control how messages are displayed, with the following choices:

• Auto — Messages are quoted automatically, as is currently implemented.
• Quoted — Messages are always quoted. This resolves the issue of misaligned lines but may reduce clarity.
• QuotedField — Messages are formatted as fields, e.g., msg="value". This approach also resolves the issue.
• Suffixed — A rare suffix is appended to the message to separate it from key/value pairs (e.g., ::).
• Raw — Messages are output exactly as they are. While this resolves the issue, it introduces several new challenges.

At this stage, adding more granular control over which characters trigger quoting seems unnecessary. This is primarily because there is ongoing work on #611 and #320, both of which aim to provide more advanced control over output formatting styles.

Here are some examples:

Auto (current)

Quoted

QuotedField

Suffixed

Raw

I think the suffixed variant provides the best readability. It presumes that if the suffix happens to appear within the message itself, the message will still be quoted for clarity. However, such occurrences are expected to be extremely rare.

[serddmitry]

Awesome choice! I like how it looks :) Thanks for your attention to my suggestions.

Suffixed options does indeed look the most readable and unambiguous, perhaps it could even be made default? Do you think this suffix could be added to formatting.punctuation config?

[pamburus]

Yes, I'm going to add the suffix to the formatting.punctuation config. Most likely, this variant will become the default.