Loading... |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hello,
Seem to be stuck. I can see that max-include-depth has a default value set to 64, however it still seems that 1 is the limit for include depth? Explicitly setting via cli max-include-depth=0 works to disable includes, but setting above 1 does not seem to make any difference. Setting depth=64 didn't work either. Is there are a trick to getting past a depth of 1 ? > asciidoctor --version Asciidoctor 0.1.4 [http://asciidoctor.org] > asciidoctor -a max-include-depth=64 -S unsafe file1 file1: THIS IS FILE ONE. + LETS INCLUDE TWO: + include::file2[depth=64] file2: THIS IS FILE TWO. + LETS INCLUDE THREE: + include::file3[depth=64] file3: THIS IS FILE THREE. Result: THIS IS FILE ONE. LETS INCLUDE TWO: THIS IS FILE TWO. LETS INCLUDE THREE: include::file3[depth=64] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Thomas, I may need to look closer into this, but my gut is telling me it has to do with the file extension. Asciidoctor doesn't process the lines as AsciiDoc in an include file if it doesn't recognize the extension as an AsciiDoc file. I have a feature request in to override this behavior, but it's not yet implemented. The easiest way is to add the file extension .adoc, .ad or .asciidoc (.asc works too, but we discourage its use) If the file extension isn't the issue, we'll need to dig deeper. Btw, you don't need to set safe mode when using the cli, only the api. The default for the cli is unsafe. I hope that gets you to the next step in solving this one! -Dan On Nov 5, 2013 3:25 AM, "thomas burger [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
Hello, ... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Dan, Thanks for the reply! I had the same feeling you did about the file extension so it was the first thing I had tried. Unfortunately, it doesn't seem to make a difference. It looks like it will process the files regardless of the extension, but it won't process the includes past a depth of one (at least for _me_). Anyone else able to pull in nested includes at a depth of 2? -thomas On Nov 6, 2013, at 3:50 AM, "mojavelinux [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Thomas, I put together a script that sets up the scenario and runs it. Give it a try and let me know if the Expected matches the Actual. If so, then you have a working example on which to build. If not, then we know that there is something specific to your use case that we need to uncover.[source,ruby] -- content = [] content << <<EOS ++++ level 1 include::level-2.adoc[] ++++ EOS content << <<EOS level 2 include::level-3.adoc[] EOS content << <<EOS level 3 include::level-4.adoc[] EOS content << <<EOS level 4 EOS (1..4).each do |l| File.open(%(level-#{l}.adoc), 'w') do |f| f.write content[l - 1] end end puts <<EOS Expect: level 1 level 2 level 3 level 4 Actual: EOS puts %x{asciidoctor -o - -s level-1.adoc} --
Also, it might be helpful if you mention what Ruby and OS you are using. I look forward to hearing the results.
On Wed, Nov 6, 2013 at 12:08 PM, thomas [via Asciidoctor :: Discussion] <[hidden email]> wrote:
... [show rest of quote] -- Dan Allen | http://google.com/profiles/dan.j.allen |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Dan, Thanks for the script. Fortunately your script ran fine in my environment. So I re-examined my earlier test, and I'm not sure why i didn't catch it last time around (probably a hasty mistake), it was the extension name that was the issue. Makes perfect sense in hindsight. The confusing thing is that: Seems like if it must enforce the correct extension, it could have thrown a friendly error on reading B.no-ext and not finding an appropriate extension? Thanks again for your help! -thomas On Nov 6, 2013, at 12:09 PM, "mojavelinux [via Asciidoctor :: Discussion]" <ml-:[hidden email]> wrote:
... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
On Wed, Nov 6, 2013 at 2:17 PM, thomas [via Asciidoctor :: Discussion] <[hidden email]> wrote:
That's good news! I'm glad you got it worked out.
The tricky part here gets back to the reason I introduced this feature. While profiling Asciidoctor on various open source projects, I noticed a high call count to the preprocessor directive methods. I realized Asciidoctor was hitting all the lines in included sources such as JavaScript, HTML, etc. Not only is that unnecessary, it runs the risk of mangling those sources. Therefore, I decided to check the extension before running the preprocessor. I think the right approach is: a) Clearly state this behavior in the docs b) Add an attribute override to the include directive that explicitly enables preprocessing (i.e., include::filename[preprocess=true]) Sound reasonable? -Dan -- Dan Allen | http://google.com/profiles/dan.j.allen
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Hi Dan,
I ran into this problem today while working on an inline variante of our documentation. I think this behavior needs still to be documented. I also tried to follow your advice and added java to the know source extensions of th Maven plugin <sourceDocumentExtensions> <sourceDocumentExtension>adoc</sourceDocumentExtension> <sourceDocumentExtension>java</sourceDocumentExtension> </sourceDocumentExtensions> But the result is still the same. The include directive in my Java source files is still ignored. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Can you start a new thread with the full context? I have no memory of what this discussion was about. Rather than try to piece it back together, it would be best if you explained the problem fresh. Best, -Dan On Sat, Feb 8, 2020 at 1:47 PM oliver.b.fischer [via Asciidoctor :: Discussion] <[hidden email]> wrote: Hi Dan, ... [show rest of quote] -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
My problem is already addressed in issue :include: should process files that don't have an AsciiDoc extension at Github.
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Administrator
|
Then go ahead and give that a thumbs up. -Dan On Sat, Feb 8, 2020 at 2:02 PM oliver.b.fischer [via Asciidoctor :: Discussion] <[hidden email]> wrote: My problem is already addressed in issue :include: should process files that don't have an AsciiDoc extension at Github. -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Did it already. Unfortunately I have only one
![]() |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Looking at these 5 emails and the issue I have no idea how they are related or what you want. You might want to clarify what your use case is and how it relates to the issue and why the partial solution already implemented is not sufficient.
David Jencks
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
![]() ![]() ![]() ![]() ![]() ![]() ![]() |
I am working on a PoC for a In-Source based documentation for a project (jQAssistant) I am working on.
Some parts of the documenation are written as standard Asciidoctor documents, other parts are embedded in our Java source code. All is aggregated via include. This works fine. What is not working is to use include in the Asciidoctor portions within the Java source code. Dan has described this behavior in a previous post. Oliver |
Free forum by Nabble | Edit this page |