You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tidy actually already has support for footnotes. Everything set via the bitfields tested for in TY_(ErrorSummary)() essentially constitutes a footnote, i.e., something that Tidy did caused Tidy to generate additional, informative output based on that action. It’s pretty neat, and I’d like to increase the use of this feature.
We’ve commented in the past that sometimes the error outputs are a bit terse, but we don’t want to make them too much longer because we want them to fit on a single line in the terminal. The error reports are a table, really. Formalizing an architecture to use footnotes would let us provide the opportunity to provide longer explanations, if requested by the user (tied with #607, giving the user more clear control of what she sees).
And for API users, I’d like to tie the footnote to the specific error message that caused the footnote (the current architecture doesn’t support this).
It would also be possible to start using the same printf arguments in footnotes as used in the error report. This could be useful in explaining more verbosely why Tidy made a particular change or flagged a particular issue. In #568, we’re also considering dropping Win XP support, meaning we could use positional arguments in these footnotes, allowing re-use of the arguments or using them in an arbitrary order versus the error message (this would not affect the current error strings).
Our output would change, for example:
Line 5 Col 1 My Error (footnote 1)
Line 12 Col 1 My Error (footnote 1)
Line 55 Col 22 Other Error (footnotes 1, 5, 12)
Tidy detected 12 errors and two warnings.
footnote 1:
Character codes for UTF-8... Lorem ispum bath salts quick foxes…
The text was updated successfully, but these errors were encountered:
Tidy actually already has support for footnotes. Everything set via the bitfields tested for in
TY_(ErrorSummary)()
essentially constitutes a footnote, i.e., something that Tidy did caused Tidy to generate additional, informative output based on that action. It’s pretty neat, and I’d like to increase the use of this feature.We’ve commented in the past that sometimes the error outputs are a bit terse, but we don’t want to make them too much longer because we want them to fit on a single line in the terminal. The error reports are a table, really. Formalizing an architecture to use footnotes would let us provide the opportunity to provide longer explanations, if requested by the user (tied with #607, giving the user more clear control of what she sees).
And for API users, I’d like to tie the footnote to the specific error message that caused the footnote (the current architecture doesn’t support this).
It would also be possible to start using the same printf arguments in footnotes as used in the error report. This could be useful in explaining more verbosely why Tidy made a particular change or flagged a particular issue. In #568, we’re also considering dropping Win XP support, meaning we could use positional arguments in these footnotes, allowing re-use of the arguments or using them in an arbitrary order versus the error message (this would not affect the current error strings).
Our output would change, for example:
The text was updated successfully, but these errors were encountered: