We have errorf
and warnf
.
I have a need to display some information, but don’t want to affect parsing of std out.
Sounds useful.
What information would be displayed?
Also it appears that there is already an internal method called Infof
:
For example, a notice about features that are enabled when building a site. It would help to answer, “Why was my site built this way?”
I’ve got an “init” partial that’s called at the top of baseof
. It does some configuration sanity checks, and it would be great if it could tell me “Hey, you’ve enabled xxx, so if the Title is upside down, that’s why.”
I would need an option on the function: whether or not to surpress additional identical messages. I don’t know if that’s possible.
I am using a debug partial that can be configured from loquacious to more silent in 10 steps and/or via debugging name (debug/info/warn/error/fatal), but still uses only warnf
and errorf
.
A sample call would be:
{{- partial "debug.html" (dict "message" (printf "Loading data configuration %s" $key) "severity" "debug") -}}
which I can silence by setting dnb.debug.level
to 8
or lower or/and dnb.debug.severity
to "warn"
or higher in my params-configuration.
Those info logs only gets printed on hugo -v
if I remember correctly, and that may not be what @jmooring wants (?) – they are easy to miss.
The reason I’m a little hesitant about adding such a function is that I like my output “clean” as possible, and this function can easily be abused by upstream components (shortcodes etc.) to add debug information that they forget to remove.
Good point.
That’s actually what triggered this question… a self-inflicted wound. I left something in that I should have removed.
I’ll just categorize warnf
per @davidsneighbour approach, and adjust std out parsing.
But what we may want to consider adding is a Warnidf
function (we have a Erroridf
function), that would allow the end user to turn off a given warning when he/she has “understood it”.
@davidsneighbour I took a look at the hugo debug tool repo the above partial is in. I think I’m going to replace my attempt at a browser debug table with this, or at least convert my attempt to a wrapper around that (if I think there is value in doing so after taking a closer look). Your debug repo look awesome, and you spend much more time on this sort of thing than I do, so I’d rather support your efforts (contributing if needed) than reinvent the wheel.
Very nice. Thank you.
I am working on implementing formatters to easily extend the debugging partial for variables. If you want to test it please refer to the latest tagged release (from two days ago) so you don’t run into unintended issues.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.