This is a log of new features of note in DWiki.
Template expansion via
#{...}now removes a final newline if such a final newline is present. (It doesn't remove more than one newline.)The final newline is really an implementation artifact of files; it's there because lines end with newlines, not because people consider it to be part of the file's real content. Deleting it thus brings template expansion closer to inserting people's idea of the file's contents into place.
It also means that we avoid having templates introduce whitespace into undesired places. For example:
[There's more starting at %{blog::seemore}#{blog/rangemore}]and
blog/rangemoreof:or %{range::moreclip}doesn't introduce a gap between the end of %{range::moreclip}'s output and the ']' in what the browser displays. (See how we didn't think of
blog/rangemoreas actually having a newline at the end as part of it?)
If {{RecentChanges}} is invoked in a {{Striped:...}} context, it now names the links to the pages by the name of the page instead of the page's full path. This turns out to be much less annoying if many (or even some) of the changes are deep in a hierarchy.
Rational: you asked for a compact display so you're going to get it.
All wikitext macros and template renderer functions now have Python docstrings. This is because there is a new macro, {{DocAll}}, that spits out a list of macros or renderers and their docstrings, thereby creating a one-stop shop for a list of them all and documentation for them.
Formatting and TemplateSyntax have been changed to use this, thereby killing several birds and a fix-me with one somewhat extended stone.
In the process of writing docstrings, I fixed several irritating limitations and renamed a few renderers.
ChrisSiebenmann likes this approach best because it keeps the documentation closely attached to the function, thereby serving as a clear visual reminder that a) change the function, update the documentation that's right there in front of him and b) write a new function, write a docstring to go with it.
Directories can now be displayed as a 'blog', which treats all file descendants of the directory as if they were blog entries and attempts to be somewhat intelligent about how much to show and how to navigate things, supporting navigation by page date or Nth to Mth most recent pages.
ChrisSiebenmann doesn't believe this makes BlogDir obsolete. BlogDir is an excellent view for ChangeLog style situations, which is exactly what NewFeatures uses it for; however, it makes a bad way of displaying a true blog-style environment because of eventual information overload. BlogView is designed to deal with that by trimming what gets displayed and providing time-based and range-based navigation.
Default directory views, mentioned before in DefaultDirViews, are now inherited from parent directories if the child specifies no particular desire about the whole thing.
This is convenient for setting an entire hierarchy to a BlogView (qv).
DWiki has a new formatting feature. If you write just '* * *' on a line by themselves, they center and become a separator. Like, well, this:
* * *
You can't indent them, because I decided that would run too much risk of confusing things with pre-formatted text blocks.
Why? I just decided I liked that style of chunk separator. (Maybe if I could get a <hr> variant that didn't stretch the entire width...)
Note: feature subject to me changing my mind.
Symbolic links inside the DWiki page area now cause redirections if their value would be a valid redirection in a REDIRECT line.
For example: FrobTig, which is a symlink in /Aliases with the value '
../People'.We could have tried using os.path.realpath() on the symlink and taking the result relative to the store root, but I think that that has more subtle explosive breakages.
Symbolic links that don't resolve to a real DWiki page this way are interpreted normally, so you can still have symlinks that point to files outside the DWiki pagestore root.
DWiki now supports 'virtual directories': directories that don't really exist but instead serve to limit what's shown for a real directory. For example, you can limit what's shown for a real directory to only the most recent 5 things, or to only things written on 2005/05/29.
DWiki's tables can now have rows that span multiple lines, using indentation to continue them on subsequent lines just like with lists. The appearance is straightforward; just write:
| start your table | another cell that is continued on another line | the end cell | | cell one | cell two | cell three |A row is closed by having a '
|' at the end of a line, or just by starting a new row.
DWiki now supports definition lists (<dl>, <dt>, <dd> in HTML). I started with what I think was Wikipedia's syntax but decided it was ugly in plain text so came up with my own that I like better.
DWiki now has a simple hierarchical way of handling access to pages for various things (both access and commentability), so you can give (or take away) permissions for things to entire directory trees at a shot. We use a simple implementation where directories can have a magic file called
__access, which creates default permissions for everything under them.
DWiki now has an extremely low-rent generic from-the-web search functionality. It's so low-rent I'm not sure I'm going to keep it, but we'll have to see.
As part of the fallout of other work, I fixed the nit where 'View Source' would show as a page tool on pages where viewing the source would get you a permission or unavailability error.
With blog-style things now decently supported, there is the problem that some pages want to be longer than is comfortable for display in a blog setting. Now wikitext can signal that only the front should be shown in some contexts, like so:
Directories can now have default view types associated with them, by the simple yet sleazy method of touching a file in them called
.flag.prefview:<viewname>.This lets us auto-set a directory to default to a blogdir view.
The page tools now autogenerate a list of 'See As <whatever>' links for alternate directory formats.
This required some innards magic to distinguish a normal view being explicitly specified from no view being specified and us just defaulting to a normal view.
Directories can now be displayed as a 'blogdir', which treats the files in the directory as if they were blog entries: they are sorted by modification time, most recent first, and then they are all displayed inline with a title.
A chunk of this behavior is controlled by templates and new renderers. 'blogdir' is a new view, only valid for directories, which uses
blogdir.tmpl. Theblog::blogdirrenderer does the direct expansion, running each file through the templateblog/blogentry.tmpl.There are also new renderers for the new blog-like time format and for showing the owner of a file. (Currently the Unix and/or RCS owner.)
This is ... how shall we say it ... not hugely scalable over the long run in terms of time structure and number of entries.