-
-
Notifications
You must be signed in to change notification settings - Fork 135
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
Block#getContent() can return Opal.nil #1692
Comments
I believe that's already the case in Asciidoctor.js 3.0.
It will actually change the behavior, in Asciidoctor.js 3.0 we return |
I think we should return undefined. I'm going to update core to return empty string when that's what it should be, but there are times when it should be undefined (block macro). |
Could you please provide a simple reproduction case where it returns Opal.nil? |
The original description provides an example case when it currently returns Opal.nil (but should return undefined). Here's another case: console.dir(Asciidoctor.load('image::test.png[]').getBlocks()[0].getContent()) We know now that this is only happening in the 2.2.x line. The 3.0.x line seems to be doing the right thing. |
For certain blocks, calling
getContent()
can return Opal.nil. Until Asciidoctor > 2.0.18 is released, this can happen if a raw (e.g., passthrough) or verbatim (e.g., listing) block has no lines.The Opal.nil return value can also happen if this method is called on a block macro. Regardless of this variation in core, I think Asciidoctor.js should protect against client code setting an Opal.nil return value.
The text was updated successfully, but these errors were encountered: