Yes, this has also been something I've missed from mostly all markup languages, but the renderer also has to make a distinction between paragraphs inside and outside of a section. To better illustrate:
@section {
@title: This is my section title
Text, paragraph, etc.
@section {
@title: Subsection Title
Text, text, text.
}
More text that belongs to the parent section. But how will the reader know that? Indentation? Blocks with background color maybe?
}
No that is how the system works today. I would like, and have always wanted a way to disambiguate without creating a new title. There should be some sort of visual indicator that we are going up to the parent level without creating a sibling to the parent.
title: ships
p: ships travel on water
p: they are like cars but on water
title: motors
p: ships have motors
p: spin around
p: very powerful
p: ships can be used for many things
title: fishing
p: fish are in water, so the incentives are super-aligned
I've been hacking now and then on a document preprocessor that uses a similar syntax, e.g. this code
@Section[name=quickstart]{@Title{Quickstart}
@P{ The official documentation is very sparse, but as a quickstart here is what you need to do: }
@List{
@Item{Create a fullscreen window to render into}
@Item{Initialize the library with @FuncRef{S3DTK_InitLib}.}
@Item{Create a renderer with @FuncRef{S3DTK_CreateRenderer}.}
@Item{Create an IDirectDraw instance - DirectDraw is mainly used to manage video memory.}
@Item{Setup exclusive and fullscreen cooperative level and set the video mode to 640x480x16bpp or whatever.}
@Item{Obtain the base of the framebuffer (see below) to use for calculating surface offsets.}
@Item{Create a primary surface with a secondary buffer attached to it to act as a swap chain.}
@Item{Create two @TypeRef{TS3DTK_SURFACE} variables to hold info about the surfaces. S3D actually needs very little info about a surface: its size, pixel/texel format and the offset in video memory from the framebuffer. This bit is the trickiest one.}
@Item{Optionally create a 16bit surface to hold a z buffer - again you need to do this via DirectDraw and @TypeRef{TS3DTK_SURFACE}.}
}
@P{ And that is about it. Beyond that it is mainly setting state and drawing triangles. In terms of memory management, S3D relies on DirectDraw to do the video memory allocation/etc so in general the process is allocating a DirectDraw surface and filling a @TypeRef{TS3DTK_SURFACE} variable with info about it. The S3D API itself does not actually know about DirectDraw, it is only used indirectly to obtain the memory offsets and to perform surface flipping. In theory it might be possible to allocate a big surface and chop it to smaller pieces with multiple @TypeRef{TS3DTK_SURFACE}s. }
produces the list at the top of [0]. The main difference in the syntax is that instead of "@title: blah" you type "@title{blah}" because "blah" is just the content for the "title" node and the parser doesn't treat any nodes in a special way, it just creates a tree and then passes it to a script for doing whatever it wants to do (to produce the linked HTML document it is passed to a script that generates HTML in a variety of formats - e.g. single file, multiple files, using HTML5 elements or sticking to "basic" HTML that works in a bunch of primitive viewers, etc).
The "Section" node above uses "P" but strictly speaking it isn't necessary as any text after the } will create text nodes for the parent node (in this case the "Section" node). I did it this way mainly for consistency, but a script could just use the node's own text (which is basically what nodes like "FuncRef", "TypeRef", etc are doing).
(i do not have any releases for the processor yet since i'm still -slowly- tweaking it as i -very slowly- write various documents using it)
Not really since i'm still tweaking it. The base processor is mostly done (though i also add some minor stuff here and there) but the scripts are incomplete. Of course one can use their own scripts instead, but i want to have a default set that works for most manual-style uses.
