NewFeatures: Chronological entries

New: Page Titles

Pages now have accessible 'titles', sort of. A page's title is taken to be the value of the header that starts the page, if said header is on the very first line. (So this page's nominal title is 'New: Page Titles'.) The header level doesn't matter; a <h6> is as good as a <h1>, so long as it's the first line on the page.

This info is available only after the page has been rendered, in the new global context variable :wikitext:title. Fortunately for us, Atom feed entries can have their fields in any order, so we are free to generate <title> after <content>.

Why did I do this? First, it's suitably low rent, and second I decided I wanted some vague way to generate semi-real page titles in Atom feeds instead of the current full path to the page (ever so helpful and informative as it is).

The only tricky bit was making sure that only the appropriate magic wikitext renderers set the page title, and not all the times that we spin through wikitext looking for, eg, permissions. (Especially important in Atom feeds, as Atom feeds look at everyone's permissions before they do the real rendering.)

A DWiki page (technically, any wikitext, so comments too) can now start with the line '#pragma pre' to declare that the entire rest of the page is simply preformatted text and should be barfed out as such (minus the #pragma line, which is swallowed). '#pragma plaintext' is accepted too.

This is a much more convenient and maintainable way to stick plaintext files (such as program source or something) into a DWiki than indenting the entirity of their text one space.

Note that this does not make the page come out as text/plain. The page is still text/html and fully templated, it's just that the wikitext is one big <pre> lump, instead of more sophisticated formatting.

It's unlikely that DWiki will acquire any other sorts of pragmas (eg to say 'format this as nicely HTML-ized Python code'), partly because ChrisSiebenmann is dubious about the 'nicely HTML-ized' bit of any formatters since they invariably involve aesthetic decisions that people (eg, him) can and do object to. Having an easy way of including plaintext is the 80%-90% solution, and that is the DWiki way.

DWiki has a new template handling scheme: the core idea is that we now have a way of a) picking the first existing template from a list of them and b) generating candidate templates by variable substitution and 'all parent directories' expansion. This gives DWiki a simple and general framework for doing things like 'template injection', which lets us skin an entire directory hierarchy (but not the entire wiki) with things like blog sidebars.

This also gives us a single top-level template that generates all normal HTML-based pages, thereby giving us a single place to skin the entire site. The per-view templates in views/* (now only a convention) now just generate view-specific information, leaving all of the rest up to the top-level template.

The clarity and lack of stupid template piece duplication of the result is a clear indication of how it is a better scheme. (And no more silly things like splitting a <div> start and end into different files and hoping they get included in the right spots.)

TemplateSyntax and TemplatesUsed have been revised appropriately.

One obvious way of handling blogs with categories is to create appropriate directory hierarchies for each category, then hardlink a page's file into all of the appropriate 'category' directories. However, this raises a problem: DWiki's idea of a page's identity is its path.

Read more »

Directories can now have Readme files, called __readme. Readme files are injected into pages via the new renderer inject::readme (probably the first of several injectors).

The current templates don't inject __readme in normal directory views, but do inject them for blog and blogdir views (as you may see from this directory). Blog and blogdir views now drop all files starting with __, taking out __readme and __access and any future special magic files.

Read more »

DWiki can now generate Atom feeds for recently changed pages and recently made comments, either for the entire DWiki or for some subtree of it. For comments, this can be down to an individual article.

At the moment, pages in the Atom feed are rendered without macros except for CutShort, for efficiency reasons. All of the links are turned into absolute links (with http:// et al), since this is basically required. Nulled-out macros produce a small message to that effect in the generated content, so that people reading the Atom feed can tell that something is going on.

Read more »

The primary way of getting nested lists is now to indent the nested list entries relative to the parent list (entry). This looks visually better in plain ASCII for cases when there is a decent amount of text.

Although ChrisSiebenmann thought he wasn't going to, the old style of nesting lists (multiple list start characters, eg ***) still works. It turns out the GNU Emacs will properly autoindent for these lists but not for real indented lists, plus sometimes they actually look visually better.

The amount of old-style nesting is ignored in an indented context; it's treated as just a new level.

You can now use LinkAbbrevs by name (not by URL) without a |; ie, instead of writing [[<text>|]], you can just write [[<text>]]. This only happens if <text> wouldn't result in a link to a real page or an external URL if there was no abbreviation.

Thus, one can write [[Google http://www.google.com/]] in the page once, and later write [[Google]], and have it work out.

DWiki now lets you use spaces to separate things in [[....]] links instead of |. If you do this, the last word is taken as the link URL or page, and the rest are the link name. (| has priority over this; DWiki tries space-separation only if there is no |.)

Thus [[Google Rules The Web http://www.google.com/]] turns into Google Rules The Web.

You can use either side as an abbeviation later, for example: Google Rules The Web, Google Rules The Web. (See View Source.)

LinkAbbrevs done this way don't have to use |, as long as there is a space in the value: [[Google Rules The Web]] still turns into Google Rules The Web.

This allows somewhat more aesthetic long link name things.

Note that the opening [[ and the closing ]] have to be on the same line in the wikitext.

A DWiki RedirectFile can now point to absolute URLs as well as local DWiki pages. Absolute URLs are written like they would be in [[...]]; either http:// or <...>.

DWiki now supports generating links to URLs on the wiki's web server that are outside the DWiki itself. These are written as links in the format <...> and have to happen inside [[...]]. For example:

See [[the root of this web server|</>]].

generates a link to the DWiki's web server's root, which is all but certain to be outside the DWiki space if you're running DWiki as a CGI-BIN.

DWiki now remembers the name and URL for links that you write with [[...|...]] and thereafter allows you to omit one side of the |, at which point it will fill in the remembered values. This means that if you want to link to Google a lot in your document, you only have to write (eg) the URL once, and can thereafter refer to Google much more compactly.

This does collide a little bit with using [[...|]] to write totally unstyled text: it only comes out unstyled if it's not already been used as the name of a link.

For now I will live with that.

The RecentChanges DWikiText macro now accepts additional arguments that are the list of directories to restrict the listing to, or with a dash at the front, directories to exclude from the listing. If you combine both, both criteria must match: in an included directory and not excluded.

This lets a RecentChanges listing exclude areas that churn too much or are otherwise less interesting to list. (Perhaps, for example, a blog sub-hierarchy in a DWiki.)

If there is a common directory prefix that scanning is limited to, the scan is efficient: only that directory and lower is looked at at all.