From 55d7ff49ecdf98d04f50dc101ce016ed5986e7bb Mon Sep 17 00:00:00 2001 From: Yuval Tassa Date: Tue, 16 Jun 2026 06:23:26 -0700 Subject: [PATCH] Fix broken link in docs. PiperOrigin-RevId: 933054777 Change-Id: Ic862992051200bff1b742025926961a7c2087ffa --- doc/programming/simulation.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/programming/simulation.rst b/doc/programming/simulation.rst index 3fc0a393..d87b25fd 100644 --- a/doc/programming/simulation.rst +++ b/doc/programming/simulation.rst @@ -986,9 +986,9 @@ architectural distinction in how filtering is applied: can implement their own filtering logic. * **DEBUG messages**: Designed for tight, high-frequency simulation loops where constructing strings would be a - performance bottleneck. Therefore, filtering happens on the **producer side** via :ref:`mju_isTopicEnabled`. If a - topic is disabled, the message is never constructed or dispatched. Consequently, custom handlers will only receive - DEBUG messages if the topic is explicitly enabled in the active :ref:`mjLogConfig`. + performance bottleneck. Therefore, filtering happens on the **producer side**. If a topic is disabled, the message is + never constructed or dispatched. Consequently, custom handlers will only receive DEBUG messages if the topic is + explicitly enabled in the active :ref:`mjLogConfig`. In the default handler, INFO messages are followed by a blank line for readability, whereas high-frequency DEBUG traces are printed compactly without trailing blank lines.