-
Notifications
You must be signed in to change notification settings - Fork 338
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
Asciidoctor: Support for "open in widget" #627
Changes from 1 commit
9a3d04e
b3fa0ec
d5fa2fb
702975e
5c30bbc
85abcf4
b74306c
e272218
cc8f3c7
1624996
0937803
5fe67cc
15ba6d2
922f3ec
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1005,12 +1005,26 @@ footnote to a particular line of code: | |
=== View in Console | ||
|
||
Code blocks can be followed by a "View in Console" link which, when clicked, | ||
will open the code snippet in Console. The snippet can either be taken directly | ||
from the code block (`CONSOLE`), or be a link to a custom snippet. | ||
will open the code snippet in Console. There are two ways to do this, the | ||
"AsciiDoc" way and the "Asciidoctor" way. The "AsciiDoc" way is preferred in | ||
the Elaticsearch repository because it can recognize it to make tests. The | ||
"Asciidoctor" way is preferred in other books, but only if they are built with | ||
"Asciidoctor". Try it first and if it works then use it. Otherwise, use the | ||
"AsciiDoct" way. | ||
|
||
.Code block with CONSOLE link | ||
//// | ||
|
||
The tricks that we pull to make ascidoctor support // CONSOLE are windy | ||
and force us to add subs=+macros when we render an asciidoc snippet. | ||
We *don't* require that for normal snippets, just those that contain | ||
asciidoc. | ||
|
||
//// | ||
|
||
.Code block with CONSOLE link (AsciiDoc way) | ||
================================== | ||
[source,asciidoc] | ||
ifdef::asciidoctor[[source,asciidoc,subs=+macros]] | ||
ifndef::asciidoctor[[source,asciidoc]] | ||
-- | ||
[source,js] | ||
---------------------------------- | ||
|
@@ -1026,6 +1040,24 @@ GET /_search | |
================================== | ||
<1> The `// CONSOLE` line must follow immediately after the code block, before any callouts. | ||
|
||
.Code block with CONSOLE link (Asciidoctor way) | ||
================================== | ||
[source,asciidoc] | ||
-- | ||
[source,console] | ||
---------------------------------- | ||
GET /_search | ||
{ | ||
"query": "foo bar" \<1> | ||
} | ||
---------------------------------- | ||
|
||
\<1> Here's the explanation | ||
-- | ||
================================== | ||
|
||
Both render as: | ||
|
||
[source,js] | ||
---------------------------------- | ||
GET /_search | ||
|
@@ -1051,38 +1083,6 @@ The local web browser can be stopped with `Ctrl-C`. | |
|
||
================================ | ||
|
||
==== Custom Console snippets | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've dropped the docs for this because I think, at least as we have it now, it is super confusing. It isn't compatible with Elasticsearch's tests or There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason these custom blocks exist is for the Definitive Guide, where we wanted to display a small amount of JSON but then click through to console to show the full example, including setup etc. Other than the Def Guide, it is not really used anywhere else There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah! I tracked that down. We've talked on and off about having some way of hiding something like these custom blocks but in a way with visual feedback for what you are getting. I'm not sure the right way to do it but I could image these making a comeback eventually. But as I have it now I'm just dropping the docs for them because I don't want people using them without really knowing what they are doing. |
||
|
||
Sometimes you will want to show a small amount of code in the code block, but | ||
to provide a full recreation in the Console snippet. In this case, you need to: | ||
|
||
* Save the snippet file in the `./snippets/` directory in the root docs directory. | ||
* Under the code block, specify the name of the snippet file with | ||
+ | ||
// CONSOLE: path/to/snippet.json | ||
|
||
For instance, to add a custom snippet to the file `./one/two/three.asciidoc`, save the snippet | ||
to `./snippets/one/two/three/example_1.json`, then add the `CONSOLE` link below the code block: | ||
|
||
.Code block with custom CONSOLE link | ||
================================== | ||
[source,asciidoc] | ||
-- | ||
[source,js] | ||
---------------------------------- | ||
GET /_search | ||
{ | ||
"query": "foo bar" \<1> | ||
} | ||
---------------------------------- | ||
// CONSOLE:one/two/three/example_1.json <1> | ||
|
||
\<1> Here's the explanation | ||
-- | ||
<1> The path should not contain the initial `snippets` directory | ||
================================== | ||
|
||
|
||
[[admon-blocks]] | ||
=== Admonition blocks | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -89,6 +89,24 @@ | |
# Because Asciidoc permits these mismatches but asciidoctor does not. We'll | ||
# emit a warning because, permitted or not, they are bad style. | ||
# | ||
# With the help of ElasticCompatTreeProcessor turns | ||
# [source,js] | ||
# ---- | ||
# foo | ||
# ---- | ||
# // CONSOLE | ||
# | ||
# Into | ||
# [source,console] | ||
# ---- | ||
# foo | ||
# ---- | ||
# Because Elastic has thousands of these constructs but Asciidoctor feels | ||
# strongly that comments should not convey meaning. This is a totally | ||
# reasonable stance and we should migrate away from these comments in new | ||
# docs when it is possible. But for now we have to support the comments as | ||
# well. | ||
# | ||
class ElasticCompatPreprocessor < Asciidoctor::Extensions::Preprocessor | ||
include Asciidoctor::Logging | ||
|
||
|
@@ -140,13 +158,21 @@ def reader.process_line(line) | |
@code_block_start = line | ||
end | ||
end | ||
|
||
supported = 'added|coming|deprecated' | ||
# First convert the "block" version of these macros. We convert them | ||
# to block macros because they are at the start of the line.... | ||
line&.gsub!(/^(#{supported})\[([^\]]*)\]/, '\1::[\2]') | ||
# Then convert the "inline" version of these macros. We convert them | ||
# to inline macros because they are *not* at the start of the line.... | ||
line&.gsub!(/(#{supported})\[([^\]]*)\]/, '\1:[\2]') | ||
# Transform Elastic's traditional comment based marking for | ||
# AUTOSENSE/KIBANA/CONSOLE snippets into a marker that we can pick | ||
# up during tree processing to turn the snippet into a marked up | ||
# CONSOLE snippet. Asciidoctor really doesn't recommend this sort of | ||
# thing but we have thousands of them and it'll take us some time to | ||
# stop doing it. | ||
line&.gsub!(%r{//\s*(?:AUTOSENSE|KIBANA|CONSOLE|SENSE:[^\n<]+)}, 'pass:[\0]') | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would consider making the regexp a constant so that it's not instantiated each time this code is called. It also has the benefit of following this file's convention of making regexp's constants. See these lines |
||
end | ||
end | ||
reader | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -23,14 +23,62 @@ | |
# <1> The count of categories that were matched | ||
# <2> The categories retrieved | ||
# | ||
# Turns | ||
# [source,js] | ||
# -------------------------------------------------- | ||
# GET / <1> | ||
# -------------------------------------------------- | ||
# pass:[// CONSOLE] | ||
# <1> The count of categories that were matched | ||
# <2> The categories retrieved | ||
# | ||
# Into | ||
# [source,console] | ||
# -------------------------------------------------- | ||
# GET / <1> | ||
# -------------------------------------------------- | ||
# <1> The count of categories that were matched | ||
# <2> The categories retrieved | ||
# | ||
class ElasticCompatTreeProcessor < TreeProcessorScaffold | ||
include Asciidoctor::Logging | ||
|
||
def process_block(block) | ||
if block.context == :listing && block.style == "source" && | ||
block.subs.include?(:specialcharacters) == false | ||
# callouts have to come *after* special characters | ||
had_callouts = block.subs.delete(:callouts) | ||
block.subs << :specialcharacters | ||
block.subs << :callouts if had_callouts | ||
end | ||
return unless block.context == :listing && block.style == 'source' | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is just a minor Ruby style thing, but I would typically only use if block.context == :listing && block.style == 'source'
process_subs block
process_lang_override block
end |
||
|
||
process_subs block | ||
process_lang_override block | ||
end | ||
|
||
def process_subs(block) | ||
return if block.subs.include? :specialcharacters | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same thing here. I would write this like: if !block.subs.include? :specialcharacters
# callouts have to come *after* special characters
had_callouts = block.subs.delete(:callouts)
block.subs << :specialcharacters
block.subs << :callouts if had_callouts
end |
||
|
||
# callouts have to come *after* special characters | ||
had_callouts = block.subs.delete(:callouts) | ||
block.subs << :specialcharacters | ||
block.subs << :callouts if had_callouts | ||
end | ||
|
||
LANG_MAPPING = { | ||
'AUTOSENSE' => 'sense', | ||
'CONSOLE' => 'console', | ||
'KIBANA' => 'kibana', | ||
'SENSE' => 'sense', | ||
} | ||
|
||
def process_lang_override(block) | ||
next_block = block.next_adjacent_block | ||
return unless next_block && next_block.context == :paragraph | ||
return unless next_block.source =~ %r{pass:\[//\s*([^:\]]+)(?::\s*([^\]]+))?\]} | ||
|
||
lang = LANG_MAPPING[$1] | ||
snippet = $2 | ||
return unless lang # Not a language we handle | ||
|
||
block.set_attr 'language', lang | ||
block.set_attr 'snippet', snippet | ||
|
||
block.parent.blocks.delete next_block | ||
block.parent.reindex_sections | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This might be more readable if all the logic was in one place. The same things I said above about def process_lang_override(block)
next_block = block.next_adjacent_block
unless next_block && next_block.context == :paragraph &&
next_block.source =~ %r{pass:\[//\s*([^:\]]+)(?::\s*([^\]]+))?\]} &&
lang = LANG_MAPPING[$1]
snippet = $2
block.set_attr 'language', lang
block.set_attr 'snippet', snippet
block.parent.blocks.delete next_block
block.parent.reindex_sections
end
end |
||
end | ||
end |
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.