Halfgeek Article Construct

Halfgeek Article Construct, or HAC, is intended to be an empirical online text format for use in online journaling, messaging, and wiki systems.

Influence of POD

The first idea was basically going to be a retooling of Perl POD, with some basic stylistic changes to improve its capabilities as a formatting language for general-purpose text. Firstly, POD's idea of headings was going to be converted into sections with a similar format:

=sect1 A Top-Level Heading

=sect2 A Subheading

In POD, it is not possible to type text that lies between two sections of the same level. An arrangement like this would not be possible:

1 First Level Heading
2  Introductory text for first subheading
3   First subheading
4    Section text
5  Introductory text for second subheading
6   Second subheading
7    Section text

In particular, the section labeled 5 above does not fit with the POD paradigm; that text would fall at the same level as 4. It's a minor point, but one I thought might be significant in certain cases. So, I decided it would be nice to have a way to end a section without starting a new heading. A =break command para (I've taken to calling the paragraphs paras) seemed appropriate.

=sect1 First Level Heading

Introductory text for first subheading

=sect2 First subheading

Section text

=break

Introductory text for second subheading

=sect2 Second subheading

Section text

=cut

This example is what the previous layout example would look like in HAC. This is only one new command para, and as it only appears in specific cases where it is needed, it would not overcomplicate things.

Another weakness of POD involves the not-specifically-defined behavior of when multiple single-line list items are followed by one with an explanation.

=over 4

=item * Item 1

=item * Item 2

=item * Item 3

Alpha, an explanation for a list item

=item * Item 4

=item * Item 5

Beta, an explanation for a list item

=back

This example has multiple possible semantic meanings in POD. Alpha may be a description for item 3 only, or for items 2 and 3, or for items 1 through 3. Beta may be a description for item 5, or for items 4 and 5. Six possible interpretations where one is expected is not acceptable in the real world, so I've been thinking about ways to implement multi-item explanations.

Right this moment, the best idea seems to be to make the drop-through behavior opt-out (basically the opposite of a C switch). This would come in the form of a "+" on every non-final item of a group.

=list *

=item Item 1

=item+ Item 2

=item Item 3

This para describes items 2 and 3

=item Item 4

=item Item 5

This para describes item 5 only

=endlist

Of course, this all assumes that I don't decide to just switch to a simpler listing method altogether.

Influence of wiki

At some point, it suddenly occurred to me that the inline markup tags in POD (which take the form B<text>) are a tad arcane, and the generalization I had in mind for them (where a link would look something like :link<< <link text> href<http://xana.us> >>) was really only going to make it worse (or at least as bad as HTML, which would defeat much of the purpose).

I came upon this realization when I took a look at wikis. The format of wiki text (in particular, wiki text with free links) is elegant, simple, and looks more like real text in source form. That's a good notion to achieve, so I started taking a look.

Instead of looking to the format of a particular wiki system, I was fortunate enough to happen upon a wiki markup standard discussion page whereon many of the strengths and weaknesses of various wiki text languages are already being discussed.

In my opinion, first of all, bounding some text with double parens to get a link out is already light-years ahead of HTML.

Hi, there.  ((http://halfgeek.org I'm a link)), and I just saved about a year of typing!

Of course, that's a little simple for my taste—I know not everyone does this, but I myself usually include title attributes (and JavaScript status-bar text to match) on links from my journal. I'm a big fan of opt-in complexity, so I figured there are all sorts of alternative syntaxes just for links alone.

((http://halfgeek.org / Halfgeek.org: A smart-aleck title / I'm a link))
((http://xana.us * The character after the URI and space bounds the title * This is link text))
((This is link text)=(http://xana.us)(I am a title))

To be continued...

See Also

• Xana
• Wiki Markup Standard