Closed nmaggioni closed 2 weeks ago
Thank you for your bug report. This behavior is intentional, because outputs like // action: xxx
are from/for Octoprint and therefore they are displayed in grey. This behavior has been the same since the beginning of the console in Mainsail.
You can find more informations about this here: https://www.klipper3d.org/G-Codes.html#respond_1
Thank you, I must be misremembering an old behavior then. Sorry for the noise.
On the other hand: would a PR with additional parsing logic centered on a custom prefix (much like what's done for // echo:
right now) be interesting for the project? Something like a configurable debug prefix that has the same graphical effect as action messages but actually gets stripped from the message's contents.
We discussing that internally, personally I am not a fan of separating User and Klipper output by color. But I use it as a regular print output and also use filters to tailor the klipper related output to what i want to see at print start. E.g.
Disclaimer: That is a combined output of my own macros + tailored klipper outputs of QuadGantryLevel and BedMeshCalibrate apative=1
For your second Question: A user defined prefix is much to risky you would be surprised how creative people gets by using special chars or even spaces. And than you deal with in some cases unexpected behavior of klipper plus the issue that you need to special tailor the regex to also find that case.
That said a pre defined prefix like // debug: xxx
might be a solution. The only issue is that people need to read the docs to find that.
@nmaggioni are you interested in making a PR for the // debug:
prefix? would you use the same color as the action outputs?
Mainsail Version:
v2.12.0
Browser:
Chrome
Device:
Desktop PC
Operating System:
Linux
What happened?
Using
action_respond_info()
in macros or directly runningRESPOND
commands prints text in the console with the default primary color.What did you expect to happen instead?
Text should be printed in greyed out (disabled) color.
How to reproduce this bug?
Call
action_respond_info("Test")
from a macro or just runRESPOND TYPE="command" MSG="Test"
: the text printed in the console will be of the standard primary color.Calling
RESPOND TYPE="command" MSG="action: Test"
, instead, prints it in the disabled (greyed out) color.Additional information:
While updating some macros I noticed that my debug output wasn't being printed in grey anymore and was getting confused with the standard logging messages printed to the console.
I remember not having to prefix the statements with anything in particular to get them to print as low-priority, disabled messages; did something change with the introduction of prompt dialogs or am I just misremembering things? Since manually prefixing the messages with
action:
makes detection work successfully once again, I have the hunch that this is a small regression or new edge case in event parsing logic.