Provide max line-length in comment filter. #454
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Frustratingly, I'm running into an oddity in Specifically the go fmt comment spec states the following about lists:
I'm not positive why there's a single-space before number lists and two spaces before dash lists, but we do NOT do this in weaver today. @lquerel Thoughts? Should I create a specific renderer for markdown for Go that abides by these restrictions? Additionally, @MrAlias What should we do if we have a nested list? Will Go (and go fmt) ignore this or fail? |
…d output to use go fmt.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #454 +/- ##
=======================================
+ Coverage 73.1% 73.9% +0.7%
=======================================
Files 49 50 +1
Lines 3716 3901 +185
=======================================
+ Hits 2718 2883 +165
- Misses 998 1018 +20 ☔ View full report in Codecov by Sentry. 🚨 Try these New Features:
|
| * <li>Use a domain-specific | ||
| * attribute | ||
| * <li>Set {@code error.type} | ||
| * to capture all errors, |
There was a problem hiding this comment.
I need to more formally pull words and remember prefix/postfix space. The library allows this and uses it, it just doesn't understand changing the line prefix over time.
I hope we can, eventually, fix this all up, I just ran out of time to tinker
| if !self.markdown.ends_with("\n\n") && !self.markdown.is_empty() { | ||
| self.markdown.push('\n'); | ||
| let _ = self |
There was a problem hiding this comment.
Why not using the add_blank_line defined just after?
There was a problem hiding this comment.
It adds a prefix, this does not. add_blank_line should be fine, I may need to go update the prefix handling code.
| if let Some(buf) = self.unbreakable_buffer.as_ref() { | ||
| // ToDo - we should error out here. | ||
| // For now, we just FLUSH this to write to the buffer. | ||
| let _ = self |
There was a problem hiding this comment.
Good question - when this happens our algorithm is basically broken. I debated between "panic"-ing and implementing.
Regarding blank lines, we have no idea what we've been buffering or why we need to buffer twice, so I think it's unlikely we have a necessary blank line, it's more likely we somehow have nested code + strong/emphasis blocks.
| if let Some(buf) = self.unbreakable_buffer.as_mut() { | ||
| buf.push_str(text); | ||
| } else { | ||
| let _ = self |
There was a problem hiding this comment.
No, unbreakable text == a cohesive word that cannot be split, e.g.
[name]: link <- we treat this as unbreakable text.
Co-authored-by: Laurent Quérel <[email protected]>
Provides naive word-wrapping capabilities to the comment filter.
Fixes #364
word_wrapconfig section with basic set of features for controlling word-wrappingtextwraplibrary, but only for pieces. Unfortunately, we need dynamic word-wrapping that is syntax-aware of markdown and html.Note: this feature is naive and likely needs to be reworked, longer term