A Test comment for my next comment.

I think I can answer (or at least point you in the direction of an answer/solution) for most of your issues.

1) [code change] I think we already have a feature request for something like this, so perhaps we just need to get it's priority increased... or someone to submit a patch. :)

2) [skinning issue/possible code change] The most robust solution would require a code change to allow a commenter to markup their comment to notify Subtext that a block of text is a comment... and then Subtext could "convert" it to formatted HTML that works with our csharp.css style sheet. Of course, some of this could also be fixed by adjusting your skin to allow

 and/or 
	 markup in the comments.

3) [upgrade] As of Subtext v1.9.4 (or so...) we've been using AJAX to submit comments, so if you upgrade this issue will go away. You can go test it at my blog (running a beta build of 1.9.6) to see what I mean.


4) [upgrade/skinning issue] As of v1.9.4 there is a 


user control to do this.
5) [upgrade] We will support this in the coming v1.9.6 release... 
6) [skinning issue] this is a matter of the skin being used and it can be changed by adjusting the CSS for this skin
7) [blog config option] Subtext supports several forms of CAPTCHA including full fledged CAPTCHA, invisible CAPTCHA, Akismet support, etc... Enabling/disabling these various forms of CAPTCHA is up the the blog owner.
I hope these answers point you in the right direction. And remember, Subtext is OSS, so you (and your readers) should feel free to contribute back to Subtext if you wish... we're always open to ideas and feedback from our community and a little help pumping out the code is nice too. :)

                

<- Sent a closing "code" tag.

oops... likes like you are allowing <code> blocks in your comments but we (Subtext) didn't do a good job of validating the input b/c I didn't send a closing tag. We should either auto-close it, or HTML Encode the unclosed opening tag.

I should probably elaborate on #7: it should be simple to see if there are any undeleted comments from the requesting IP greater than a certain age, and if so, skip the CAPTCHA. I wasn't arguing against a CATCHA at all (spammers be damned), but against requiring one when it is trivial to trust me. :-) I promise I won't release my awesome spamming engine that has made me billions of dollars.

Sadly, Luke's request regarding whitelisting his IP address is only tenable in a mythical world populated only with static IP addresses. In the real world, an IP address can't even be trusted for a single request, let alone a chronology of them. ;)

That issue with not closing your comment tags is fixed in the next version of Subtext, soon to be released.

@Jeremy,

It sucks if you have a dynamic IP that changes often. However, if there have been several non-spam comments and zero spam messages in the past N days, then I believe it is highly likely that the next comment will not be spam. Thus, I do not see how my plan fails, at least for those with relatively static IPs.

For dynamic IPs, one could always do a cookie that gets some unique value from the server. I don't think we need to worry about spammers sniffing such cookies...

I also miss RSS for comments.

In my opinion that would increase debate on particular issue and

increase number of page visits and comment replies.

There's no point bothering with custom code to handle IP's and cookies when SubText already has support for Akismet and Invisible CAPTCHA (which just verifies that the user agent can eval a JavaScript statement).

Seems like a silly thing to complain about. Every user has to type "orange" to post a comment on codinghorror, and plenty of readers have managed that. After typing a few hundred characters in a comment, is 4 more that much of a hardship? Maybe it's a good thing - a short waiting period to prevent rash comments. ;-)