`. --[[smcv]]
+
+ >>> I got to wondering if the icons are needed. On my comments branch
+ >>> (not master), I've dropped the icons and info can be seen by hovering
+ >>> over the author's name. Idea being that you probably don't care how
+ >>> they authenticated unless something is weird, and in that case you
+ >>> can hover to check. Does that make sense, should I merge it?
+ >>> --[[Joey]]
+
+ >>>> Yeah, go ahead. I preferred my layout with the author before the
+ >>>> comment - perhaps that's Livejournal's influence :-) - but I can always
+ >>>> edit the templates for my own site. As long as the default is something
+ >>>> reasonable and both layouts are possible, I don't really mind.
+ >>>> Minimizing the number of "resource" files in the basewiki also seems
+ >>>> a good goal. --[[smcv]]
+
+* Previews always say "unknown IP address"
+
+ > Fixed in my comments branch by commits bc66a00b and 95b3bbbf --[[smcv]]
+
+* The Comments link in the "toolbar" is to `index.html#comments`, not the
+ desired `./#comments`
+
+ > Fixed in my comments branch by commit 0844bd0b; commits 5b1cf21a
+ > and c42f174e fix another `beautify_urlpath` bug and add a regression test
+ > --[[smcv]]
+
+
+* Now that inline has some comments-specific functionality anyway, it would
+ be good to output `` in Atom and the equivalent in RSS.
+
+ > Fixed in my comments branch by d0d598e4, 3feebe31, 9e5f504e --[[smcv]]
+
+
+* 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]]
+
+ >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it).
+ >> Sorry, I'm on mobile Internet at the moment... --[[smcv]]
+
+ >>> merged by [[Joey]] in commit 0f03af38 --[[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.
@@ -29,57 +130,41 @@ Known issues with the [[plugins/comments]] plugin:
> 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.
-
- > 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]]
+ >> I'll consider this solved by [[Joey]]'s changes. --[[smcv]]
* One can use inline to set up a feed of all comments posted to any page.
- Using template=comments_display they are displayed right. Only problem
+ 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.
-* 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/comment/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]]
+ > done --[[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