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

Resolve paths in block macros similar to asciidoc's include directive #230

Closed
basvandijk opened this issue Jul 10, 2019 · 4 comments
Closed

Comments

@basvandijk
Copy link

basvandijk commented Jul 10, 2019

To quote the documentation of diagram block macros regarding path resolving:

When the source file name is a relative path it is resolved with respect to the location of the document being processed.

Here the "location of the document being processed" means the path that the asciidoctor tool was applied to.

A more user-friendly, consistent and composable behavior would be if path resolving would work exactly like the asciidoc include directive:

  • If the include directive is used in the main (top-level) document, relative paths are resolved relative to the base directory. (The base directory defaults to the directory of the main document and can be overridden from the CLI or API).
  • If the include directive is used in a file that has itself been included, the path is resolved relative to the including (i.e., current) file.

The second point is especially important for composability: often, big documents are broken up in several .adoc files that form a hierarchy. A master or super document might include other sub documents which might again include other sub documents. It's important that users can apply asciidoctor to sub documents alone instead of always only applying it to the super document.

For this to work paths to diagrams referenced in sub documents need to be relative to the sub document such that they can be resolved both when processing the sub document alone or when processing the super document.

Also, block macros are very similar to include directives; they both reference external files. So it would make sense to have consistent behavior regarding path resolving. The fewer surprises the better.

@mojavelinux
Copy link
Member

mojavelinux commented Jul 10, 2019

AsciiDoc (as implemented by Asciidoctor or AsciiDoc Python) does not (yet) have sub documents. There's simply no such concept. Therefore, we cannot base decisions on locations of these documents because that's just not how it works (currently).

This has been discussed many times and we are still making plans for a solution. See asciidoctor/asciidoctor#650 (comment)

@mojavelinux
Copy link
Member

mojavelinux commented Jul 10, 2019

As I've discussed before, we could introduce a document macro (not preprocessor directive) that would have awareness of the structure of the document and could thus establish a "current context". This will never be how the include directive works because the include directive combines files before the lines are parsed. (But this is not the place to discuss that. It's in asciidoctor/asciidoctor#650).

@basvandijk
Copy link
Author

I think the indir extension might do exactly what I need. I'll try it out and report back here.

@pepijnve
Copy link
Member

Closing due to lack of feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants