/{....} as a template comment, because I think I want them. (maybe
another character, but ehh; this sort of looks like a C/etc comment.)
inode ctime is last modified, inode mtime is created. The split has started. This may or may not work well; I'll have to see. (Partly based on what else screws with ctimes in our Unix environment.)
It seems clear that ctime is not too useful in at least some context. I should use it for safety in Atom feed generation and some other contexts, but not otherwise by default.
http://projects.edgewall.com/trac/wiki/WikiFormatting documents some stuff better than me, plus has 'processors'. I could steal that.
Searching needs to be less lame, at least for searching through the searchbox. It probably wants to be case-independant and possibly only for word starts (instead of word boundaries on both sides; arguably all searches should be only word boundary start ones).
The real rule is not 'identifier boundary', it is 'identifier component boundary', which is \b or a-z0-9 at the start, and \b or A-Z at the end.
It should be possible to create an Atom feed template that included all of the comments as part of the page.
CSS work. This implies that I need to actually understand CSS. I laugh at myself, hollowly. (Progress: we now style some stuff with CSS.)
We should be able to see the history page for any RCS-but-not-displayable page.
There should be some form of RecentChanges that throws in time information. (Clearly not Striped'able.)
Do I want a 'render this page as wikitext' magic template option? That's what the injectors hard-code right now.
writecomment needs some way to generate a good link to help/DWikiText, so that people can actually know what to write a comment in. (It has one now, but the way may be a bit lame.)
Do we need a way to turn off WikiWord links? (The current approach is
to use [[...|]], which is perhaps good enough for the rare cases.)
Should we forbid switching to alternate views in a virtual directory? The 'normal' view doesn't work entirely right (drops subdirectories); this may be a bug. (Fixed now: the listdir renderer needs to always include all subdirectories, despite their timestamps possibly being outside the restriction.)
We need to sort out when a link stays in the same view and when it doesn't. At the moment it is somewhat ad-hoc.
[[...]] links don't chase redirects, and they should. Well, now
they do and I'm not convinced it's the right thing. It's convenient,
but it changes the explicitly written link text; this might be good or
it might be bad.
Decide: should access restrictions look sort of like Unix access restrictions, being enforced top-down, or the current bottom-up way? I am starting to think that bottom-up is open to some reliability issues. But on the other hand, top-down has semantic issues too.
Profile the code. Laugh hysterically. Fix what I can.
DWiki should be more configurable through the filesystem. Can we support adding new views (directory and/or file) by reading the canonical template directory, for example? This would suffice for anything that doesn't require special handling.
DWiki knows a lot about what views do what. Unfortunately I suspect
that this is impossible to work around, especially given how
htmlviews.py is set up.
Templates should mark up with <div> and so on.
wikirend.py needs to style-mark much of the things that it emits.
I would like to find some general augmentation mechanism, although
it's probably not going to be pretty.
We're going to need to genericize access control. I think it will be some matrix of view + file patterns + file attributes. (Punt for now, everyone can see everything.)
This is a permanently FIXME page.