Skip to content

Asciidoctor: Handle snippets in definition lists #680

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.

Sign up for GitHub

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

Merged
merged 6 commits into from
Mar 14, 2019
Merged

Asciidoctor: Handle snippets in definition lists #680

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
bd32de2
Asciidoctor: Handle snippets in definition lists
nik9000 Mar 7, 2019
6ff1d7d
Style
nik9000 Mar 12, 2019
d410a5c
Context
nik9000 Mar 12, 2019
40ed756
Subject
nik9000 Mar 12, 2019
3ac0589
Merge branch 'master' into snippet_fix_in_definition_list
nik9000 Mar 13, 2019
0ed1da8
Different rspec
nik9000 Mar 13, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion resources/asciidoctor/lib/elastic_compat_tree_processor/extension.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,13 @@ def process_subs(block)
}.freeze

def process_lang_override(block)
next_block = block.next_adjacent_block
# Check if the next block is a marker for the language
# We don't want block.next_adjacent_block because that'll go "too far"
# and it has trouble with definition lists.
next_block_index = block.parent.blocks.find_index block
return if next_block_index.nil?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it would be more idiomatic to write return unless next_block_index

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I wrote it I felt like "This can only be nil or a string so I should be explicit" but I've come around to your way.


next_block = block.parent.blocks[next_block_index + 1]
return unless next_block && next_block.context == :paragraph
return unless next_block.source =~ %r{pass:\[//\s*([^:\]]+)(?::\s*([^\]]+))?\]}

Expand Down
16 changes: 16 additions & 0 deletions resources/asciidoctor/spec/elastic_compat_tree_processor_spec.rb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -96,4 +96,20 @@
expect(actual).to eq(expected.strip)
end
end

it "doesn't mind when the snippet inside a definition list" do
actual = convert <<~ASCIIDOC
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I mentioned this in the last PR I reviewed, maybe eventually you can use context and let blocks instead in the specs.
For example, this case would have a context when the snippet is inside a definition list and then the it block would be generates the correct string (or whatever). The actual and expected variables would be let blocks.
But I think that change would be part of a larger rspec refactor and perhaps out of the scope of this PR.

This is an example of how context blocks and let blocks can be used.

== Example
Term::
Definition
+
--
[source,js]
----
GET /
----
--
ASCIIDOC
expect(actual).to match(%r{<programlisting language="js" linenumbering="unnumbered">GET /</programlisting>})
end
end