Skip to content
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

Open
mojavelinux opened this issue Apr 9, 2023 · 4 comments
Open

Block#getContent() can return Opal.nil #1692

mojavelinux opened this issue Apr 9, 2023 · 4 comments

Comments

@mojavelinux
Copy link
Member

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.

console.dir(Asciidoctor.load('----\n----').getBlocks()[0].getContent())

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.

@ggrossetie
Copy link
Member

I believe that's already the case in Asciidoctor.js 3.0.

Asciidoctor > 2.0.18 is released

It will actually change the behavior, in Asciidoctor.js 3.0 we return undefined but when building against Asciidoctor > 2.0.18 we return ''. Should Iwe return undefined or ''?

@mojavelinux
Copy link
Member Author

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).

@ggrossetie
Copy link
Member

but there are times when it should be undefined (block macro).

Could you please provide a simple reproduction case where it returns Opal.nil?

@mojavelinux
Copy link
Member Author

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.

@ggrossetie ggrossetie modified the milestones: v3.0.x, v2.2.x Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants