X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/470c46c79481a9017f28d4b7ec661fe073b00fa2..c5ea0c7ce6ee9f374d6346d491c84e515eca21e3:/doc/todo.mdwn?ds=inline diff --git a/doc/todo.mdwn b/doc/todo.mdwn index 3e2374a4f..a2211ba2c 100644 --- a/doc/todo.mdwn +++ b/doc/todo.mdwn @@ -1,124 +1,7 @@ -## online page editing +Welcome to ikiwiki's todo list. Link items to [[todo/done]] when done. -* Eventually, might want page deletion. -* Eventually, might want file upload. +Also see the [Debian bugs](http://bugs.debian.org/ikiwiki). -## recentchanges - -* Should support RSS for notification of new and changed pages. - - This can be a static rss file that is generated when the moo -is built. (As long as all changes to all pages is ok.) - -* Should support mail notification of new and changed pages. - - Hmm, should be easy to implement this.. it runs as a svn post-coommit hook - already, so just look at the userdb, svnlook at what's changed, and send - mails to people who have subscribed. - - A few details: - 1. [[Joey]] mentioned that being able to subscribe to globs as well as - explicitly named pages would be desirable. - 2. I think that since we're using Perl on the backend, being able to - let users craft their own arbitrary regexes would be good. - - Joey points out that this is actually a security hole, because Perl - regexes let you embed (arbitrary?) Perl expressions inside them. Yuck! - - It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --[[Joey]] - - 3. Of course if you do that, you want to have form processing on the user - page that lets them tune it, and probably choose literal or glob by - default. - - The first cut, I suppose, could use one sendmail process to batch-mail all - subscribers for a given page. However, in the long run, I can see users - demanding a bit of feature creep: - - 4. Each user should be able to tune whether they see the actual diff parts or - not. - 5. Each user should be able to set a maximum desired email size. - 6. We might want to support a user-specified shibboleth string that will be - included in the email they receive so they can easily procmail the messages - into a folder. - - --[[BrandenRobinson]] - -## pluggable renderers - -I'm considering a configurable rendering pipeline for each supported -filename extension. So for ".mdwn" files, it would send the content through -linkify, markdown, and finalize, while for ".wiki" files it might send it -through just a wiki formatter and finalize. - -This would allow not only supporting more types of markup, but changing -what style of [[WikiLink]]s are supported, maybe some people want to add -[[CamelCase]] for example, or don't like the [[SubPage/LinkingRules]]. - -The finalize step is where the page gets all the pretty junk around the -edges, so that clearly needs to be pluggable too. - -There also needs to be a step before finalize, where stuff like lists of pages -that linked back to it could be added to the page. However, doing linkbacks -also needs to tie into the main logic, to determine what pages need to be -renered, so maybe that won't be a plugin. - -## revisit case - -Being case insensative is handy, but it does make the [[BackLinks]] a bit -ugly compared to other links. It should be possible to support pagenames -that have uppercase, while still allowing them to be linked to using any -case. - -## html - -Make the html valid. Add css. - -## sigs - -Need a way to sign name in page that's easier to type than "--\[[Joey]]" -and that includes the date. - -What syntax do other wikis use for this? I'm considering "\[[--]]" (with -spaces removed) as it has a nice nmemonic. - -OTOH, adding additional syntax for this would be counter to one of the -design goals for ikiwiki: keeping as much markup as possible out of the -wiki and not adding nonstandard markup. And it's not significantly hard to -type "--\[[Joey]]", and as to the date, we do have page history. - -## recentchanges links to commit diffs - -Would take a bit more viewcvs integration, let the be a "[diff]" link in -recentchanges that goes to the diff for any listed change. - -## recentchanges more than 100 - -Possibly add "next 100" link to it, but OTOH, you can just use svn log if -you need that data.. - -## search - -* full text (use third-party tools?) -* list of all missing pages -* list of all pages or some kind of page map - -## page indexes - -Might be nice to support automatically generating an index based on headers in a page, for long pages. The question is, how to turn on such an index? - -## page locking - -Some wikis will need the abiity to lock a page, or the whole wiki, so that only admins can edit them. Probably using the same globbing as for recentchanges mails to determine what to lock. - -Probably it's ok if locking is only supported for web commits. - -## User settings page - -A cgi page to allow a user to log out and to edit their prefs, including password, email, and anything we add later (subscriptions, etc). - -## Logo - -ikiwiki needs a logo. I'm thinking something simple like the word "ikiwiki" with the first "k" backwards; drawn to show that it's "wiki" reflected. - -## [[Bugs]] +[[inline pages="todo/* and !todo/done and !link(todo/done) and !todo/*/*" +feedpages="created_after(todo/supporting_comments_via_disussion_pages)" +actions=yes rootpage="todo" postformtext="Add a new todo item titled:" show=0]]