-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(parser/renderer/types): Support inline and image icons #613
Conversation
This adds inline icon support, and significantly refactors the icon handling to bring in support for image based icons and all of the icon attributes supported by asciidoctor, bringing us to feature parity. Additionally, we preserve some of the attributes from the font icon tags onto images, allowing flip, rotate, and size styles to be applied to icons. (This is an improvement over asciidoctor, and requires supporting CSS.) One subtle difference when comparing output. We emit source paths for images without a leading "./". That is because our use of path.Join() automatically removes the redundant portion. Fixes bytesparadise#587 Fixes bytesparadise#611 Fixes bytesparadise#610
Removed unused items, and consolidated down to just one icon type.
Codecov Report
@@ Coverage Diff @@
## master #613 +/- ##
==========================================
+ Coverage 86.69% 86.78% +0.09%
==========================================
Files 68 69 +1
Lines 4239 4322 +83
==========================================
+ Hits 3675 3751 +76
- Misses 360 363 +3
- Partials 204 208 +4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! I just put some comments to ask you to add tests on other types of elements, to make sure that inline icons and images are properly parsed everywhere. But I believe that there's no need to verify all combinations of attributes again ;)
@@ -388,7 +388,8 @@ TitleElement <- element:(Word | |||
/ Space+ | |||
/ CrossReference | |||
/ InlinePassthrough | |||
/ InlineImage | |||
/ InlineIcon | |||
/ InlineImage |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add a few tests just to make sure that inline icons/images can be parsed in title elements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it turns out that we only render plain here. (Just like for images.) It's possible that this decision could be revisited. I think the ability to render images and icons inside a title could be useful. What will happen now is you'll get the Alt text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I guess that only happens for section 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, wait. I guess its for the table of contents only. Lol.
@@ -717,6 +718,7 @@ LabeledListItemTermElement <- element:(Word | |||
/ ConcealedIndexTerm | |||
/ IndexTerm | |||
/ InlinePassthrough | |||
/ InlineIcon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add a few tests just to make sure that inline icons/images can be parsed in labeled list terms?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm doing this .. so they only work in labeled list descriptions.
The grammar does not permit any markup in the terms. This should probably be considered a defect, but not one that I'm going to fix right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(It's a preexisting defect.)
@@ -964,6 +967,7 @@ DoubleQuoteBoldTextElement <- Word | |||
/ MonospaceText | |||
/ SubscriptText | |||
/ SuperscriptText | |||
/ InlineIcon |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you add a few tests to verify that inline icons/images can be parsed in quoted text?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
Co-authored-by: Xavier Coulon <[email protected]>
Co-authored-by: Xavier Coulon <[email protected]>
The definition lists and the ToC renderer didn't handle icons properly.
}) | ||
|
||
It("inline icon in quoted text", func() { | ||
source := `an _italicized icon:warning[] message_` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry to insist, but could you add a test for each kind of quoted text? (bold, monospace, etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh. Ok. The parser tests are a royal pain. I have come to really despise the test framework -- it is almost impossible to read the output when there is an error sometimes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can try something like this:
ginkgo -focus "my test" pkg/parser -- -debug
with the -debug
flag passed to the test, you'll have a dump of the actual result, so it's sometimes easier to compare with the expectation. Sometimes the diff is enough, but not always
next time let's try to have a single PR per issue, so it's easier to review. But I imagine that you found out the bugs while working on the PR and probably wanted to address them immediatley? |
Yes, it would have been a pain to do this in separate PRs, the fixes were not easily separable. I filed the tickets to log the issue, but splitting the work up not so easy. |
sure, I understand the context here. It's just a good practice I want us to have here, to make PR focused and reviews simpler ;) |
thanks @gdamore 🙌 |
This adds inline icon support, and significantly refactors the icon handling
to bring in support for image based icons and all of the icon attributes
supported by asciidoctor, bringing us to feature parity.
Additionally, we preserve some of the attributes from the font icon tags onto
images, allowing flip, rotate, and size styles to be applied to icons.
(This is an improvement over asciidoctor, and requires supporting CSS.)
One subtle difference when comparing output. We emit source paths for images
without a leading "./". That is because our use of path.Join() automatically
removes the redundant portion.
Fixes #587
Fixes #611
Fixes #610