[Proposal] Embedding other markup without adding more grammar

[danielepolencic]

Before I raise any PR, I wanted to check if this is feasible.

I'm writing a story and I'd like to include Markdown as the markup language. There's a bit of overlap between markdown & Ink and a few characters should be escaped. Example:

-> Menu

=== Menu ===

\**Select one**
_Select one_
`Code`

listitem:
1. item1

\- item1
\- item2

\--- // new line

There are a few more edge cases (escaping URLs, for examples). Searching in the issues for this repo reveals:

• Issues with the *. https://github.com/inkle/ink/issues/275
• URLs. https://github.com/inkle/ink/issues/153#issuecomment-617548445
• Hash symbols https://github.com/inkle/ink/issues/560
• Square brackets https://github.com/inkle/ink/pull/385

Most of the issue can be solved with escaping — e.g. \*. But if the text contains several of those, it's really hard to write a story and escape all the characters as well.

I looked in the documentation for an instruction to escape a block of text. Example:

-> Menu

=== Menu ===

{raw
**Select one**
_Select one_
`Code`

listitem:
1. item1

- item1
- item2

--- // new line
}

But I realised that Ink doesn't offer such functionality.

I tried to look for other workarounds and realised that I could escape the text with a function:

EXTERNAL md_bold(string)

-> Menu

=== Menu ===

{md_bold("Hello")} World!

-> END

The issue is that I can't have arguments that span multiple lines:

EXTERNAL MARKDOWN(string)

-> Menu

=== Menu ===

{MARKDOWN("Hello
new line")} World!

-> END

So I was wondering if it is possible (and acceptable) to contribute a feature to:

• Either extend the language with a new word to escape blocks of text.
• Extend function arguments to span multiple lines.

Thanks, Dan

P.S.: Both features enable a (convenient? annoying?) side effect. I can embed any other markup language in Ink and I can write my own extensions without changing the compiler.

[joethephish]

Hmmm, the multi-line string option wouldn't work, since ink string literals are actually embedded/nested ink themselves! As in, you can do ~ myVaryingThing = "hello {world|New York}!".

You cooooould maybe do the {raw ... } thing, though I'm not particularly fond of the syntax? I feel like if we do this at all (that I'm not really 100% convinced by to be honest), then I'd rather use a more compact syntax, such as "" ... "", or backticks, or @" .... " or something? Though yeah, I'm also not fond of yet more obscure punctuation-based syntax...

[danielepolencic]

Hmmm, the multi-line string option wouldn't work, since ink string literals are actually embedded/nested ink themselves! As in, you can do ~ myVaryingThing = "hello {world|New York}!".

TIL

You cooooould maybe do the {raw ... } thing, though I'm not particularly fond of the syntax? I feel like if we do this at all (that I'm not really 100% convinced by to be honest), then I'd rather use a more compact syntax, such as "" ... "", or backticks, or @" .... " or something? Though yeah, I'm also not fond of yet more obscure punctuation-based syntax...

I'm not familiar enough with the code to recommend syntax or implementation. I'd like to find a workaround to embed markdown without escaping most of the chars. If that means backticks instead of {raw}, that works for me.

I guess I'm open to everything at this point. Someone mentioned doing a sort of include with FUNCTION("my file.md"). That works too, but I'd rather edit the text in ink, if possible.

If this feature is unlikely to spark joy, is there any other workaround I could try?

Thanks for the prompt reply, btw.

[weaversam8]

I'd also find the ability to embed other markup (like markdown) incredibly helpful. I'd be fine with any of the syntaxes proposed, but I think a punctuation based syntax (maybe even triple backticks ```) would be best.

I've considered building a workaround for this by writing a markdown file with ink code blocks within it, but I think it's probably better for this to exist in the Ink language. If Ink is supposed to be a tool for managing branching narrative that's designed to be embedded in other tools, the ability to use more complex markup is definitely desirable. (Especially flavors that have already been established rather than a roll-your-own solution.)