typos

[git.ikiwiki.info.git] / doc / todo / comments.mdwn

diff --git a/doc/todo/comments.mdwn b/doc/todo/comments.mdwn
index 38c61287cc9dd0f864d12e08a56a662626864401..aa6b130dc737449782e08997b33318ea5f6c73df 100644 (file)
--- a/doc/todo/comments.mdwn
+++ b/doc/todo/comments.mdwn
@@ -2,12 +2,88 @@ Known issues with the [[plugins/comments]] plugin:
 
 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
   should probably be shared
 
 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
   should probably be shared

+
+  > Actually, there's less of this now than there used to be - a lot of simple
+  > things that were shared have become unshareable as they became more
+  > complex. --[[smcv]]
+

 * Previews always say "unknown IP address"
 * Previews always say "unknown IP address"

+

 * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID
 * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID

+
+  > Done in my comments git branch --[[smcv]]
+
+  > Not seeing it there, which branch? --[[Joey]] 
+

 * The default template should have a (?) icon next to unauthenticated users (with the IP address
   as title) and an OpenID icon next to OpenIDs
 * The default template should have a (?) icon next to unauthenticated users (with the IP address
   as title) and an OpenID icon next to OpenIDs

+
+  > Done in my comments git branch, at least as a mockup (using the (?),
+  > {x} and {*} smileys for anonymous, OpenID and login respectively).
+  > --[[smcv]]
+

 * Should the comments be visually set off more from the page above?
   Rather than just a horizontal rule, I'm thinking put the comments
   in a box like is used for inlined pages.
 * Should the comments be visually set off more from the page above?
   Rather than just a horizontal rule, I'm thinking put the comments
   in a box like is used for inlined pages.

+
+  > I did put them in a box in the CSS... I agree the default template
+  > could do with visual improvement though. --[[smcv]]
+

 * Instead of just a link to add a comment, it could have a form to enter
   the title, similar to the form for adding a new blog post.
 * Instead of just a link to add a comment, it could have a form to enter
   the title, similar to the form for adding a new blog post.

+
+  > I'm not sure this is so useful? On Livejournal titles are allowed on
+  > comments, but very rarely used (and indeed usually not very useful);
+  > it's hard enough to get some people to title their blog posts :-)
+  > --[[smcv]]
+
+* If a spammer posts a comment, it is either impossible or hard to clean
+  up via the web. Would be nice to have some kind of link on the comment
+  that allows trusted users to remove it (using the remove plugin of
+  course).
+
+  > Won't the remove plugin refuse to remove internal pages? This would be
+  > a good feature to have, though. --[[smcv]]
+
+* One can use inline to set up a feed of all comments posted to any page.
+  Using template=comment they are displayed right. Only problem
+  is there is no indication in that template of what page each comment in the
+  feed is a comment on. So, if a comment is inlined into a different page,
+  I think it should show a link back to the page commented on.
+  (BTW, the rss feed in this situation seems ok; there the link element
+  points back to the parent page.
+
+  > done --[[Joey]] 
+
+* It would be useful to have a pagespec that always matches all comments on 
+  pages matching a glob. Something like `comment(blog/*)`.
+  Perhaps postcomment could also be folded into this? Then the pagespec
+  would match both existing comments, as well as new comments that are
+  being posted.
+
+  > Please see [[plugins/comments/discussion]]. If I've convinced you that
+  > internal pages are the way forward, then sure, we can do that, because
+  > people who can comment still won't be able to edit others' comments
+  > (one of my goals is that commenters can't put words into each other's
+  > mouths :-) )
+  >
+  > On the other hand, if you still want me to switch this plugin to "real"
+  > pages, or if internal pages might become editable in future, then
+  > configuring lockedit/anonok so a user X can add comments to blog pages
+  > would also let X edit/delete comments on blog pages (including those
+  > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]]
+
+  > I had a look at implementing comment() and fell afoul of 
+  > some optimisations that assume only internal() will be used to match
+  > internal pages. So probably this isn't worth doing. --[[Joey]] 
+
+* One of Joey's commit messages says "Not ideal, it would be nicer to jump to
+  the actual comment posted, but no anchor is available". In fact there is
+  an anchor - the `\[[_comment]]` preprocessing wraps the comment in a <div>
+  with id="comment_123" or something. I'll fix this, unless Joey gets there
+  first. --[[smcv]]
+
+  > done --[[Joey]] 
+
+* Now that inline has some comments-specific functionality anyway, it would
+  be good to output '<link rel="comments">' in Atom and the equivalent in RSS.