Use `` syntax not only to include images, but also text files

[AvtechScientific]

Use ![alt](path) syntax not only to include images, but also text files.

See: https://github.com/jgm/djot.js/issues/85

"This commit enables the creation of structured documents of arbitrary complexity, contrary to the current state of affairs where only one-pagers are allowed. So now if one needs to write a book or a lengthy article all the content must be in one file. Working with big files is not convenient and may slow down/crash the editor besides being hard to read. File inclusion, implemented in https://github.com/jgm/djot.js/pull/94, allows the author to subdivide the book/article into separate manageable chapters. This provides djot with the power similar to that of LaTeX and makes it positively distinct from all the Markdown-like tools."

And a ready to merge PR: https://github.com/jgm/djot.js/pull/94

[Omikhleia]

Sorry, but there's a discrepancy between this description and what the code does. I see some code related to footnotes, etc. So what does it mean? What are the implications for other Djot implementations?

[Omikhleia]

Also, sorry, but this is bragging, and weird:

This provides djot with the power similar to that of LaTeX and makes it positively distinct from all the Markdown-like tools.

In my own workflows, I use a higher level master document file (above Djot etc.), and I have made printed books from front cover to back cover with them, assembling bits of Djot content (and also Markdown or other, when needed). I don't see anything being solved "positively" here.

[AvtechScientific]

If you include files - there might be colliding identifiers, like e.g. footnote names. In such a case the renderer warns the user and it is up to the user to handle the issue. Again - no manipulation with the content.

On Sun, Jun 30, 2024 at 12:26 AM Omikhleia @.***> wrote:

Sorry, but there's a discrepancy between this description and what the code does. I see some code related to footnotes, etc. So what does it mean? What are the implications for other Djot implementations?

— Reply to this email directly, view it on GitHub https://github.com/jgm/djot/issues/307#issuecomment-2198341512, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC6NCK7QZ5YBWZ76AUFVL63ZJ4Q7PAVCNFSM6AAAAABKDPCGQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGM2DCNJRGI . You are receiving this because you authored the thread.Message ID: @.***>

[AvtechScientific]

In my own workflows, I use a higher level master document file (above Djot etc.), and I have made printed books from front cover to back cover with them, assembling bits of Djot content (and also Markdown or other, when needed). I don't see anything being solved "positively" here.

Using your own workflows can you handle this simple case of two included files:

File_1: Is this **bold

File_2: or not?**... hmm

Master_File: ![File_1](./File_1) ![File_2](./File_2)

If yes - how do you do it?

[Omikhleia]

I certainly would forbid breaking semantic structures between different files. What your example above is even aiming at solving ? You do really expect someone to start a bold structure in a file... and end it in another, seriously?

[Omikhleia]

Speaking of semantics, what becomes the "alt" content in your ![alt](somefile.djot) ?

[AvtechScientific]

Speaking of semantics, what becomes the "alt" content in your ![alt](somefile.djot) ?

Just to stay consistent with the image case - alt will be displayed if somefile.djot is not found.

[AvtechScientific]

I certainly would forbid breaking semantic structures between different files. What your example above is even aiming at solving ? You do really expect someone to start a bold structure in a file... and end it in another, seriously?

1. Judging by the lack of a solution on your side I conclude that you have no solution.
2. The above mentioned example was intended for demonstration purposes only. If you can't think of a practical example for this - I'll help you. Inclusion, i.a., enables templates. Let's imagine a document that consists of 2 constant sections - header and footer, and a variable middle section (e.g. a letter to company employees were the variable middle section consists of employee names being programmatically injected). Header might open an inline element (bold, italic or whatever) that footer will close. It's just one example. I think the real life can bring more.

[Omikhleia]

Just to stay consistent with the image case - alt will be displayed if somefile.djot is not found.

How consistent? In pandoc-flavored markdown, what you call the "alt" text may be used as the figure legend if the image stands alone in a paragraph of its own (see the "implicit figure" option). The Djot syntax is not very clear yet about this use case, and it does not have a general provision either for captioned images and figures -- for reference, see notably discussions https://github.com/jgm/djot/issues/28 and https://github.com/jgm/djot/issues/87, amongst other. But whether it eventually goes the same way as in pandoc (using the bracketed text as implicit figure) or via a generalization of the (currently table-only) ^ legend markup, the issue would remain the same.

Judging by the lack of a solution on your side I conclude that you have no solution.

Sympathetic. But I recognize I wouldn't have a solution for a non-issue edge case with no clear semantics defined ;)

You mention templating - I'm not even that sure it should be part of the document syntax... And real templating goes far beyond mere content injection. (For the mere record, however, I already need and use some sort of custom templating logic too, see https://github.com/jgm/djot/issues/238, in specialized Djot-based template files. I do think the real life can bring more, indeed.)