]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/recentchanges.mdwn
* Wrap the editpage template in the standard misctemplate, this allows the
[git.ikiwiki.info.git] / doc / todo / recentchanges.mdwn
index dc5d3611bf613913e9cb3d4a48b52a743a3c838a..d46c0d9a88704055eec9daf607dff1f12dc6e029 100644 (file)
@@ -54,14 +54,35 @@ etc.) Virtual pages would "expire" and be deleted if they were not
 depended on in some way.
 
 Let's say these pages are created in edits/commit_%d.mdwn. RecentChanges
-would then be a page which did nothing but inline the last 50 edits/*
+would then be a page which did nothing but inline the last 50 `edits/*`
 This would give static generation and RSS/Atom feeds. The inline 
-plugin could be optionally altered to inline pages from edits/* 
+plugin could be optionally altered to inline pages from `edits/*` 
 that match any pages in its pagespec, and through this we could get
-a recent-changes+pagespec thing.
+a recent-changes+pagespec thing. You could also exclude edits that have
+"minor" in the commit message (or some other thing that marks them as
+unremarkable).
 
 You could make an argument that I care way too much about what amounts
 to edits anyhow, but like Josh says, there are use cases for this. 
 While this could be done with mail subscriptions, I can think of sites
 where you might want to disable all auth so that people can't edit
 your pages. --Ethan
+
+> I really dislike all Wiki engine recentchanges pages.  They all tend to be
+> fairly machine readable, but confusing for non-wiki users to grok.  And I've
+> yet to see an _attractive_ recentchanges implementation.  IkiWikis' is no
+> better or worse than the others.
+>
+> I really like the frontpage of [Bill
+> Seitz](http://webseitz.fluxent.com/wiki/FrontPage) as an recentchanges
+> format.  Note how he uses some clever css to show changes in different
+> sections of the website.  I modeled my own
+> [recentchanges](http://xtermin.us/recentchanges) page page on his ideas.  This
+> probably isn't appropriate for non-WikiLog style setups, but is this
+> something closer to what you what was requested?
+>
+> BTW: My recentchanges plugin does not seem to add a lot processing time
+> to compiling.  Then again, I'm not pulling changelog message from the RCS 
+> backend.
+>
+> -- CharlesMauch